| 10 Nov 2025 |
 piegames | Which one? | 08:20:17 |
 K900 | Platform equality | 08:20:28 |
 Qyriad | In reply to @piegames:flausch.social
That would be possible but honestly feel weird it would make comparison trinary, ¯\_(ツ)_/¯ | 08:20:52 |
| piegames | How so? | 08:21:29 |
| K900 | Expr::eq(this, that) -> MsoTristate | 08:21:36 |
| K900 | When | 08:21:36 |
| Qyriad | you're probably right that it's better to not, though | 08:22:03 |
| K900 | (in case anyone isn't familiar, https://learn.microsoft.com/en-us/dotnet/api/microsoft.office.core.msotristate?view=office-pia) | 08:22:29 |
| piegames | What I dislike is that you have some data structure, it compares nicely, now you want to add a helper function that manipulates the data, suddenly your data has no equality anymore | 08:24:22 |
| Qyriad | yeah that's whatI don't like either | 08:57:14 |
| Qyriad | * yeah that's what I don't like either | 08:57:34 |
 Rutile (Commentator2.0) feel free to ping | == vs ===? /hj | 09:11:18 |
| Qyriad | ban == for sets entirely and require defining a __eq? /hj | 09:11:58 |
| piegames | So my take is that for most data structures ("types"), the code doesn't change between most instances. So it could be factored out of the comparison. Only attrs that actually need per-value functions to be different would be incomparable | 09:16:14 |
| piegames | Yknow, just the normal stuff from most every other language | 09:16:25 |
| K900 | I mean having a user defined __eq would be good for other reasons as well | 09:17:59 |
| K900 | But it's also a super hard compat break | 09:18:06 |
| Qyriad | I think something that is clear at the least is that Nixpkgs lib should have a lib.attrsets.equalsWithoutFunctions or something | 09:23:42 |
 Sergei Zimmerman (xokdvium) | It is there btw | 09:23:58 |
| K900 | There's lib.platforms.equals or something | 09:24:20 |
| K900 | But it will never be used consistently if the obvious thing is allowed | 09:24:30 |
| Sergei Zimmerman (xokdvium) | Also lib.systems.equals is horribly slow and inefficient | 09:25:04 |
| K900 | Imagine having sane platform definitions | 09:25:21 |
| K900 | tbh | 09:25:22 |
| Sergei Zimmerman (xokdvium) | I wanted to highlight that, yeah. There's no supporting the borked equality semantics with a more "optimized" object model. You either a) ditch support for old nix expressions b) suffer the lack of manoeuvrability in terms of the implementation. | 09:27:50 |
 Taeer Bar-Yam | In reply to @piegames:flausch.social
The would probably not mesh well with future performance optimisations What future performance optimisations are you thinking of? Maybe we can solve those problems too! | 13:53:59 |
| Taeer Bar-Yam | So one issue I'm seeing is that "best effort" or "marginal effort" function equality checking will tend to be unstable because the set of functions we can determine equal, and the set of functions that we can distinguish between will both fluctuate based on our implementation.
How's this for a plan?
(a) fix nixpkgs so it doesn't use function equality checking
(b) output a warning when people try to use function equality checking. something to the effect of "this is unstable and exists for backwards compatibility"
(c) maintain an unstable version of function equality checking, that is only guaranteed to work in situations where function equality currently works.
We can introduce a flag --no-function-equality like we have --no-url-literals
That way people can continue to evaluate old versions of nixpkgs, but people are unlikely to depend on how the features is implemented now (certainly in nixpkgs), so we are free to adjust it to new implementations, even though it breaks edge cases, since nobody will be using those edge cases.
| 15:14:21 |
| piegames | Bytecode interpreter with compiler optimizations, inlining, common subexpression elimination etc | 16:13:23 |
 aloisw | What is tristate about that? It has five values out of which three are "not supported". | 17:04:22 |
| K900 | That's the joke yes | 17:11:26 |
