markdown stuff

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
+```

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

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: