| 12 Dec 2025 |
 emily | which works right up until it really doesn't | 13:34:53 |
| emily | it would be fun to see the module system modelled in Haskell including the part where you have mutually recursive options and config where the former define the types for the latter. I suspect you can pull it off with enough {-# LANGUAGE #-} | 13:37:04 |
 Arian | https://cuelang.org/docs/concept/the-logic-of-cue/ | 13:39:11 |
| Arian | imo cue comes pretty darn close | 13:40:57 |
| emily | isn't CUE explicitly dynamically-typed? | 13:48:20 |
| emily | I suspect Nickel might be doing something closer | 13:48:59 |
| Arian | Depends on what you mean with dynamically typed. It’s a lattice. So you can do static analysis by merging with an abstracter lattice | 13:51:34 |
| emily | (I know types-as-values/more general dependent typing can make this a fuzzy question already because you have type-checking recursing into evaluation, so for clarity I mean "you cannot type-check an expression with a free variable of known type but unknown value, right?" - but I could be wrong.) | 13:52:22 |
| Arian | the static-ness of a defintion is a nice partial order with types at the top and uninhabited values at the bottom. Slice the lattice was much as yo need | 13:52:23 |
| emily | right... I guess you can try evaluating by just setting the variable to its type. hmm... | 13:52:46 |
| Arian | yes… or to a static constraint | 13:53:03 |
| emily | IIRC CUE has limited control flow, right? I am not sure if the properties would scale to making it a "real PL" | 13:53:45 |
| emily | e.g. I don't see how you could typeck a recursive branching function in this way | 13:54:15 |
| emily | which sort of scuppers it as a model for Nix | 13:54:24 |
| emily | eh, maybe you could with enough memoization. wouldn't work for polymorphic recursion but that's a high bar. | 13:55:11 |
| Arian | cue doesn’t have functions. it’s more a model of the NixOS module system; not of nix | 13:55:12 |
| Arian | my thesis is that nix is a terrible host language for the NixOS module system :P | 13:55:20 |
| emily | yeah | 13:56:08 |
| emily | well I don't like the module system anyway, it's too global. throws away half of the properties that make Nix nice for package graphs. | 13:56:34 |
 KFears (burnt out) | I really like modules. Functional package graphs get weird and very global when splicing and pkgsStatic and build variants become a thing | 16:06:05 |
| emily | I don't think the module system solves the issue of variant sets | 16:24:52 |
| emily | (it just doesn't really have to deal with it in practice since people do the equivalent thing with NixOS much less, although still not zero) | 16:25:33 |
| emily | the equivalent of NixOS modules for the package set would be if every package definition in Nixpkgs could monkey-patch any other package arbitrarily | 16:26:32 |
 llakala | In reply to @emilazy:matrix.org
well I don't like the module system anyway, it's too global. throws away half of the properties that make Nix nice for package graphs. i will plug my fav alternate module system | 18:17:22 |
| llakala | https://github.com/adisbladis/adios | 18:17:42 |
| llakala | it's basically what I always wanted in a module system | 18:18:20 |
| llakala | where it only evaluates the modules you actually use | 18:18:35 |
| llakala | i did some eval profiling for my use of it and it only adds about 2% extra evaluation time - the rest is just from the drvs | 18:19:43 |
| llakala | since the docs are pretty barebones (something I'm hoping to fix), you can see real-world usage here https://github.com/llakala/nixos/tree/6e15be6cae6a9051f763e34ae711460751672df7/wrappers | 18:20:41 |
| llakala | modules can read from the config values in another module, and with my new PR, you can even mutate another modjle | 18:22:05 |
