| 11 Jul 2023 |
 profpatsch | nbp: does SOS fix the strictness problem of merging options? | 12:58:24 |
 nbp | SOS has nothing to do with modules, so no. | 12:58:45 |
| nbp | SOS focuses on replacing all override* by the update operator. | 12:59:07 |
| profpatsch | Or rather, does it reduce the power of the module system (modules can depend on each others’ config values recursively and cycic-ly) | 12:59:15 |
| profpatsch | because that power is the main reason for the slowness | 12:59:32 |
| profpatsch | you can’t expect a global arbitrary fixed-point to be performant, because there’s literally no optimizations you can make | 12:59:52 |
| profpatsch | esp if you want the result to be a maximally lazy data structure, which for packages definitely has to be the case | 13:00:28 |
| profpatsch | you can say what you want about callPackage, but laziness it does preserve | 13:01:00 |
| nbp | What makes NixOS slow is the delegation of properties. If instead of delegating properties one level at a time, you were to spam all options covered by it … that would reduce the memory and time. | 13:01:15 |
| nbp | This might actually be doable in Nix … | 13:01:28 |
| profpatsch | nbp: what do you mean by “delegation of properties”? | 13:04:06 |
| nbp | mkIf cond { foo = …; } ==> { foo = mkIf cond …; } | 13:05:14 |
| nbp | mkIf cond { a.b.c.d.e.f.g.h.i = …; } ==> { a = mkIf cond { b.c.d.e.f.g.h.i = …; }; } ==> … ==> { a.b.c.d.e.f.g.h.i = mkIf cond …; }
What I am saying is that we could remove the intermediate steps. | 13:08:10 |
| profpatsch | nbp: how would you remove those steps? You have to go layer by layer, no? | 13:22:16 |
| profpatsch | > This transform is the critical step that allows mkIf conditions | 13:23:02 |
| profpatsch | to refer to the full configuration without creating an infinite | 13:23:02 |
| profpatsch | recursion. | 13:23:02 |
| profpatsch | That’s exactly what I mean, this is too much power | 13:23:10 |
| profpatsch | the semantics of a system like that shouldn’t be “you can refer to any option in any module at any time as long as you don’t create cycles” | 13:23:34 |
| profpatsch | Maybe a DAG-like structure or even a tree-like structure should be allowed, but a fixed point is too much to be able to optimize | 13:24:06 |
| nbp | The problem is not the fixed-point. This is like saying there is a for-loop, we should remove the loop and explicit every step done by the for-loop. | 13:25:56 |
| nbp | Yes, this gives power, and that's what makes NixOS modules great. Otherwise this would be called Guix, and you could only access things that were given to you as options that you could forward … but this would be worse, because either someone would forget to give you the option, or you will have to check for a ton of empty options provided to you. | 13:27:28 |
| profpatsch | The problem wouldn’t exist if there was no fixpoint | 13:27:33 |
| nbp | If there was no fix-point, then you will have the same problem, except that you would not be able to blame it on the fix-point. | 13:28:16 |
 raitobezarius | nbp: curious about this SOS draft | 13:29:50 |
| raitobezarius | Is this going to be developed in the public :> ? | 13:30:06 |
| profpatsch | yes, what I’m saying is nixos would be better off if modules had defined inputs and outputs | 13:30:37 |
| raitobezarius | (have you considered looking into Tvix too? It may be easier to do large scale changes depending on what you are interested, but it has some bugs and it's not cppnix) | 13:30:40 |
| nbp | At the moment my head is not public. :P | 13:30:42 |
| profpatsch | And if modules could only forma DAG | 13:30:45 |
