1.3 KiB
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:
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