| 11 Jul 2023 |
 profpatsch | raitobezarius: It’s fundamentally impossible to make it fast as far as I understand, but I’d love if it were otherwise | 12:27:34 |
| profpatsch | If you can get it to work without having to strictly evaluate all options first, then you might be able to | 12:28:15 |
| profpatsch | but then you have something that’s not the nixos module system anymore, because the semantics is different | 12:28:36 |
 nbp | It would be possible to make NixOS module use less memory and potentially be faster … by implementing it in C++.
But one must understand that the module system, while not evolving frequently is still evolving. And from my point of view, of someone who never managed to get anything large accepted in Nix source code, this is a not an option. | 12:30:54 |
 infinisil | It could be implemented as a Nix plugin | 12:31:50 |
| nbp | Not mentioning the fact that evolution would be restricted to evolution of the Nix binary. | 12:31:54 |
| nbp | Can Nix plugin extend the grammar, to experiment new syntax / primitive? | 12:34:01 |
 @piegames:matrix.org | In reply to @infinisil:matrix.org
It could be implemented as a Nix plugin Are these a thing already? What can they do? | 12:42:09 |
| @piegames:matrix.org | In reply to @nbp:mozilla.org
Can Nix plugin extend the grammar, to experiment new syntax / primitive? Simply being able to efficiently implement external functions exposed in Nix would probably be sufficient | 12:42:47 |
| * @piegames:matrix.org dreams of a WASM interface to Nix, to be able to implement complex functions efficiently in other languages, without being tied to the Nix code base | 12:43:36 |
| nbp | the reason I am asking is for S.O.S. implementation. | 12:43:38 |
| nbp | * the reason I am asking is for S.O.S. implementation draft. | 12:43:59 |
| 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 |
