| 11 Jul 2023 |
 profpatsch | s/attributes/attrsets/ | 17:16:35 |
| profpatsch | I bet you can fit defaults and mkForce etc in there, too | 17:17:03 |
 @piegames:matrix.org | Actually merging itself, and having that in the type system isn't that big of a deal IMO. Problems arise if you expect to merge values with inter-dependencies. Like, Nixpkgs config requires merging as there are multiple places where the configuration can be but, but they are all independent from each other so it's a lot simpler | 17:18:26 |
| profpatsch | priority is pretty simple to fit in, Priority { prio :: Int, value :: a } is a monoid by taking the value with the higher priority | 17:18:36 |
| @piegames:matrix.org | Oh, what you're saying is "default values are just merging with priority"? | 17:19:54 |
| @piegames:matrix.org | But how about default values without otherwise merging functionality | 17:20:11 |
| @piegames:matrix.org | * But how about default values without otherwise merging functionality? | 17:20:13 |
| profpatsch | so mkForce just becomes the function mkForce val = Priority { prio = highestPriority, value = val } | 17:20:20 |
| profpatsch | actually not sure you want to use monoids here, since having an identity element might not be the default you want in most cases? | 17:22:40 |
| profpatsch | so monoid sans empty element might be a better choice | 17:22:53 |
| profpatsch | piegames: I guess default values could just be values with very low priority? | 17:23:59 |
| profpatsch | idk | 17:24:01 |
| profpatsch | I mean if you think about it nixos configs are very similar to CSS in that regard | 17:24:34 |
| profpatsch | mkForce is !important | 17:24:38 |
| @piegames:matrix.org | The thing I don't like priority for, is that now you have to track which values are actual values, and which values are priority annotation wrapping a value. | 17:25:18 |
| profpatsch | thus is the tyranny of structured typesystems | 17:26:30 |
| profpatsch | *structural | 17:26:38 |
|  dish [Fox/It/She] changed their display name from Pyrox [ She/They/Xem ] to Pyrox [ It/She/They/Xem ]. | 20:43:38 |
| 12 Jul 2023 |
 @yannham:matrix.org | Ah, funny to see that a lot of the subjects touched upon here are questions we also had to think about for Nickel as well. Would be interesting to share some of the ideas and insights on both side. A couple points:
- We have Profpatsch 's approach to defaults and forces: those are just priorities. But in Nickel priorities are builtin, and somehow orthogonal to the value (stored inside metadata), so the interpreter just transparently ignores them. That is,
{foo | default = 5}.foo is just 5, without having to care about the priority. To override it, you need to merge it with something else which defines a new value for foo.
- I think that some form of static dependency tracking is important as well. Because scoping is lexical, we mostly use free variables, which seems to be a reasonable over approximation (that is, you can determine statically what fields in the final fixpoint another field depend on). I guess you could even be smarter about record accesses (if you only see
options.bar and options.baz, then you can avoid depending on options.whatever and other fields).This also paves the way for incremental evaluation.
merging is different from typechecking
conflating the two is a big source of annoyance
| 07:22:24 |
| @yannham:matrix.org | Profpatsch: would you care elaborating on that? CUE seems to take the entirely opposed approach | 07:22:44 |
| @yannham:matrix.org | * Profpatsch: would you mind elaborating on that please? CUE seems to take the entirely opposed approach | 07:24:43 |
| @yannham:matrix.org | * Ah, funny to see that a lot of the subjects touched upon here are questions we also had to think about for Nickel as well. Would be interesting to share some of the ideas and insights on both sides. A couple points:
- We have Profpatsch 's approach to defaults and forces: those are just priorities. But in Nickel priorities are builtin, and somehow orthogonal to the value (stored inside metadata), so the interpreter just transparently ignores them. That is,
{foo | default = 5}.foo is just 5, without having to care about the priority. To override it, you need to merge it with something else which defines a new value for foo.
- I think that some form of static dependency tracking is important as well. Because scoping is lexical, we mostly use free variables, which seems to be a reasonable over approximation (that is, you can determine statically what fields in the final fixpoint another field depends on). I guess you could even be smarter about record accesses (if you only see
options.bar and options.baz, then you can avoid depending on options.whatever and other fields).This also paves the way for incremental evaluation.
merging is different from typechecking
conflating the two is a big source of annoyance
| 07:33:02 |
| @yannham:matrix.org changed their display name from Yann Hamdaoui to yannham. | 07:46:09 |
| profpatsch | yannham: Cue suffers from the same slowness problems as the nixos module system afaik | 08:41:28 |
| profpatsch | The problem is unscoped merging, aka if you want to figure out whether something exists, you have to potentially search through every module definition | 08:42:25 |
| profpatsch | Priority is a pretty horrible monoid, because you cannot use laziness to short-circuit | 08:42:43 |
| profpatsch | compared to e.g. Last | 08:42:54 |
| profpatsch | (there could always be something with higher priority that the evaluator hasn’t seen yet, so you have to look at absolutely everything) | 08:43:33 |
| profpatsch | I don’t know how nickel solves this? | 08:43:57 |
 nbp | Almost the same story for SOS, the intent was to not remove mkDerivation but delay it to be executed at the very end of the fix-point, thus making packages just ordinary attribute sets available through prev/super, which can be overwritten by using Nix's update operator within Nixpkgs' overlays. | 10:00:03 |
