| 26 Mar 2026 |
 raitobezarius | lix will provide reference implementations for eval, build and store | 17:12:45 |
 zoë (she/her) | hmmm i see | 17:13:00 |
| zoë (she/her) | damn i didn't think rpc implied that many things | 17:13:09 |
| raitobezarius | the role of lix is to provide reasonably advanced, performant and useful reference implementations for eval, build and store | 17:13:13 |
| raitobezarius | but also people can expand this core | 17:13:18 |
| zoë (she/her) | no wonder yall are talking about it all the time x) | 17:13:20 |
| raitobezarius | they can interop with alternatives | 17:13:22 |
| raitobezarius | etc. | 17:13:25 |
| raitobezarius | it's a key part of our strategy yes ^^ | 17:13:44 |
 FireFly | sort of tangental, but there's also the old RFC: https://github.com/nixos/rfcs/blob/master/rfcs/0134-nix-store-layer.md (for cppnix/predating lix fork) which I think is broadly aligned in the philosophy (if not necessarily execution) | 19:11:23 |
| FireFly | ooh, congrats on the release ^^ and exciting changes, I should give it a spin | 19:15:05 |
 EsperLily [she/her] | that would be the problem, if dynamic attributes had recursive semantics. they don't, so there is no dependency loop, as there's no dependency on them to form a loop. i really think the right answer here is to just make sure the documentation on recsets mentions that dynamic attributes in a recset may refer to the statically-known keys in the recset, but that the dynamic keys do not participate in the recursive semantics themselves | 19:59:15 |
 emily | it's a bit surprising that it's different to how e.g. with handles dynamic attributes | 20:15:20 |
 sterni | i don't think that's quite comparable since it is not possible to give the attributes of a with scope access to that scope | 21:00:03 |
| sterni | (except via fix points) | 21:01:38 |
| emily | right I meant let self = with self; … | 21:02:39 |
| sterni | I think it would be nice to be in a situation where these weird things desugar in an obvious way to let … in { inherit …; }, but then dynamic attrs would be disallowed. | 21:03:27 |
| sterni | hm right | 21:03:32 |
| emily | (OTOH it's not like with's behaviour is good either. with and rec are just both awful.) | 21:07:48 |
| emily | (but it does seem especially surprising when they differ) | 21:08:17 |
| sterni | it seems to me that the behavior is almost entirely the result of the overcomplicated implementation that sort of just is a result of how it was orignially implemented | 21:24:31 |
| sterni | as opposed to conscious decision | 21:25:25 |
| emily | I believe some of the weird stuff about how with handles shadowing is intentional | 21:25:53 |
| emily | but rec yeah I suspect had zero thought put into it | 21:25:58 |
| emily | and certainly ${"a"} = …; and ${"a" + ""} = …; behaving differently is very hard to justify | 21:26:06 |
| emily | leaks into flakes too btw :') | 21:26:22 |
| sterni | yes I was referring to attribute sets and let … specifically | 21:47:36 |
| sterni | since those share code and behavior but with very disturbing results | 21:48:05 |
| emily | if only we had static typing, then with rec would not be cursed and let would not need to exist | 22:01:27 |
| raitobezarius | this should go on the iceberg | 22:22:39 |
