| 12 Dec 2025 |
 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 |
| llakala | * modules can read from the config values in another module, and with my new PR, you can even mutate another module | 18:22:11 |
| llakala | but both of those are done with explicit dependency relationships | 18:22:34 |
| llakala | i think of it as "a recursive `callPackage` set on steroids" | 18:23:31 |
| emily | looks interesting, thanks | 18:42:00 |
| emily | I definitely hate the global namespace / lack of POLA a lot more than the monoid, so it's nice to see something tackling that | 18:42:35 |
