| 11 Jul 2023 |
 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 |
| 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 |
