From 295bbad3963014e27338707515443009e1a7b966 Mon Sep 17 00:00:00 2001 From: Emile Clark-Boman Date: Mon, 9 Feb 2026 09:36:50 +1000 Subject: [PATCH] markdown stuff --- NOTE.md | 11 +++++++++++ README.md | 6 ++++++ nt/CHECK_LIST.md | 6 ++++++ 3 files changed, 23 insertions(+) create mode 100644 NOTE.md diff --git a/NOTE.md b/NOTE.md new file mode 100644 index 0000000..0b2db0d --- /dev/null +++ b/NOTE.md @@ -0,0 +1,11 @@ +also I never really answered "why does Nix need a type system", it's basically because `nixpkgs` relies on a LOT of naive types under the hood. the most notable being `result = success: value: { inherit success value; };` and the excessive use of the `throw`/`abort`. Like if we pretend `builtins.getAttr` doesn't exist and try implement it from scratch we have two options: return a naive type (like the previous `result`) or raise the panic handler. Both are terrible solutions. Specifically with the first solution, too much reliance on naive types means memorizing what functions return what attribute set structure, and reinventing functions to do basic operations on them. Plus since the naive types are really just attribute sets we can do operations on them like any other attribute set (ie `builtins.attrNames`). NixTypes instead provides an alternative `nt.builtins` for people to use that ensure this never happens. Nix primitives types then have isomorphisms to their NixTypes counterpart so we can do implicit type coercion. Plus there's no reinventing the wheel, we don't have to define an `unwrapResult` operation because in NixTypes `Result` implements `Wrap` so we can do this: +```nix +myResult +|> Wrap.unwrap + +# which implicitly uses the morphism defined by Result implementing Wrap. +# we can do type coercion explicitly via: +myResult +|> as Wrap +|> Wrap.unwrap +``` diff --git a/README.md b/README.md index f6d7389..ed2aca5 100644 --- a/README.md +++ b/README.md @@ -3,10 +3,16 @@ >[!WARNING] > ✨ **Under Construction** ✨ +> > NixTypes is **quite** a large project to do alone, but it's been staring at me for the last 12 months. > If you're interested feel free to contact me and/or submit pull requests :yellow_heart::yellow_heart: +> > **Be not afraid!** It's only a matter of time until NixTypes is ready for use! +>[!CAUTION] +> The current syntax is quite ugly and **no it's not final.** NixTypes is in an +> **extremely experimental** prototyping stage! + ## 💙 Huh? Nix has no type system duh!? Sure that's fine for configuring your distro, but what about developing in Nix itself? The code people write tends to be unnecessarily complex diff --git a/nt/CHECK_LIST.md b/nt/CHECK_LIST.md index d0e9dd8..3cb123d 100644 --- a/nt/CHECK_LIST.md +++ b/nt/CHECK_LIST.md @@ -1,7 +1,13 @@ +- [ ] Write out beginner examples of how someone can import nt in a flake and also a nix expression +- [ ] Fix the README.md "Parse The Parcel" example to use a different nt function (projectOnto allows additional attributes which we don't want) - [ ] mix should warn explicitly or have an "allowShadow" & "allowShadowPredicate" decl option when content will be shadowed +- [ ] allowing shadowing be enabled by mix, but all the backend shit should be in parsing related functions +- [ ] extend the parsing system +- [ ] implement the pattern matching system - [ ] mix should do a deeply nested merge, not a surface level merge - [ ] implement isomorphisms (especially from primitives to NixTypes) +- [ ] NOTE TO SELF: what would a "Category Oriented Programming" paradigm look like? (is that my goal with NixTypes?) A Generic Type/Class could be implement to use like: