| 24 Feb 2026 |
 K900 | I mean it shouldn't be that much bigger but it will also undo the stacking trick | 09:55:14 |
 Sergei Zimmerman (xokdvium) | TVL’s fork of 2.3 did play around with that too | 09:55:16 |
| K900 | I wonder if there's like A Paper somewhere | 09:56:39 |
| Sergei Zimmerman (xokdvium) | In reply to @k900:0upti.me
I mean it shouldn't be that much bigger but it will also undo the stacking trick It would add quite a bit of pointer chasing even with a high degree of internal nodes too. And memory usage would probably jump by a lot. If the order is defined in the strings then lookup then also does string comparisons | 09:57:25 |
| K900 | I mean btrees shouldn't be that pointer chasey | 09:58:06 |
| K900 | With big enough node sizes | 09:58:12 |
| K900 | I think the rustc people found that it's basically even perf wise | 09:58:32 |
| K900 | When rustc got switched from hashmaps to btreemaps in a bunch of places | 09:58:41 |
| K900 | For r11y | 09:58:43 |
| Sergei Zimmerman (xokdvium) | I mean, if somebody does the crazy and switches to be a better representation that’d be great. FWIW there’s an immutable CHAMP implementation in immer that connor baker tried using for attrsets | 10:04:28 |
| Sergei Zimmerman (xokdvium) | But that’s not exactly the thing we want for a well-defined lexical order. For now sorting on demand doesn’t seem to cost too much to be a blocker for fixing the impurity | 10:06:48 |
| Sergei Zimmerman (xokdvium) | * I mean, if somebody does the crazy and switches to a better representation that’d be great. FWIW there’s an immutable CHAMP implementation in immer that connor baker tried using for attrsets | 10:10:21 |
 piegames | In reply to @piegames:flausch.social
Any alternative solutions to this? How about always evaluating all values in comparisons, so that eval order does not matter because it's not as lazy? | 10:17:35 |
| piegames | Or how about treating values that throw as incomparable instead of propagating it up and beyond the comparison? | 10:18:22 |
| Sergei Zimmerman (xokdvium) | In reply to @piegames:flausch.social
Or how about treating values that throw as incomparable instead of propagating it up and beyond the comparison? It’s not really only about throw expressions though. Forcing all values would be a workable, though a more radical solution | 10:20:49 |
| piegames | Do we have numbers on how many comparisons even happen in Nixpkgs? My assumption would be that it's not that common and that most instances already fast forward because of the pointer comparison | 10:23:30 |
| Sergei Zimmerman (xokdvium) | Something like ~1M that doesn't shortcircuit and falls through to per-attr equality | 11:19:04 |
| Sergei Zimmerman (xokdvium) | For all drv-paths via -qaP --drv-path for x86_64-linux | 11:19:44 |
| Sergei Zimmerman (xokdvium) | That doesn't count derivation outPath equality and size mismatches of attrs | 11:21:33 |
 emily | the pointer comparison is hideously impure so not a good reason to not reduce existing impurity | 13:49:32 |
| K900 | Do we really want to say that flakes are hard frozen? | 13:49:47 |
| emily | the ordering also matches attrNames/attrValues | 13:49:49 |
| K900 | I feel like it's fine to pick some one-line patches that fix things | 13:50:03 |
| emily | so attrsets already have a canonical ordering | 13:50:04 |
| piegames | @k900:0upti.me that depends on whether that change may cause conflicts in the migration, I don't know the state of that CC @raitobezarius:matrix.org | 13:51:18 |
 raitobezarius | I am sorry I am failing to understand the conversation | 13:51:46 |
| raitobezarius | I read things on pointer comparisons from emily and things about flakes | 13:51:54 |
| raitobezarius | Can someone TLDR me? | 13:51:57 |
| raitobezarius | or repeat what they want from me | 13:52:00 |
| emily | i.e. you can implement an ordered-by-attrname == in Nix today (modulo pointer equality) | 13:52:13 |
