| 11 Nov 2025 |
 raitobezarius | we can offer recursive pointer equality, one-off pointer equality, sharing pointer equality, etc. | 15:04:45 |
| raitobezarius | We could also consider making functions comparable | 15:04:53 |
| raitobezarius | like $$\alpha$$-equivalence of lambda terms via bisimilarity or idk | 15:05:10 |
| raitobezarius | * like $$\alpha$$-equivalence of lambda terms via bisimulation or idk | 15:05:16 |
 KFears (burnt out) | I think there are many various ways to compare functions that can be useful in different contexts (string comparison, signature comparison, evaluated comparison, pointer comparison), and it might be weird to prefer one over another. Maybe having no "default" comparison but having options to choose from would be best? | 17:42:38 |
| raitobezarius | I did https://wiki.lix.systems/books/lix-contributors/page/pointer-equality to expand my thoughts and current understanding | 18:07:04 |
| raitobezarius | I feel like there's two directions from the current local optimum (?) we are, kicking function equality out of the language, figuring how far we are willing to go to repair lack of structural equality for complicated types like functions | 18:08:20 |
| raitobezarius | pennae are more in favor of kicking the thing out because there's no practical value to offer a real == for fns | 18:08:47 |
| raitobezarius | i was in favor of making == for functions complete, i.e. recursive ptr equality + semantic check if ptr equality fails | 18:09:07 |
| raitobezarius | but i sat down and looked how to do it and noped out | 18:09:17 |
 Sergei Zimmerman (xokdvium) | Quip: nix eval "github:nixos/nixpkgs?rev=a999c1cc0c9eb2095729d5aa03e0d8f7ed256780#pkgsCross.gnu64.bitwarden" --no-eval-cache. This wasn’t a regression and doesn’t evaluate under any nix impl. It was the case where nixpkgs machinery thought that it was doing this in cross and thus failed to eval | 18:09:42 |
| raitobezarius | aaaaaaaaah thanks | 18:09:54 |
| raitobezarius | well the other thing was a regression no? | 18:10:00 |
| raitobezarius | i know something that evals only on lix head now | 18:10:06 |
| Sergei Zimmerman (xokdvium) | In reply to @raitobezarius:matrix.org
well the other thing was a regression no? Yeah, some old nixos config from flake-regressions | 18:10:40 |
| raitobezarius | yeah, ok it was indeed from flake-reg | 18:11:32 |
| raitobezarius | (i imagined that and therefore i did yesterday: https://git.lix.systems/raito/flake-regressions) | 18:11:48 |
| raitobezarius | This is going into the pennae's direction from my understanding | 18:12:31 |
| raitobezarius | People can decide to have a cmp fn function they use in their local context | 18:12:44 |
| KFears (burnt out) | In reply to @raitobezarius:matrix.org
This is going into the pennae's direction from my understanding Yeah | 18:14:11 |
 Taeer Bar-Yam |
no practical value to offer a real == for fns
except backward compatibility, right?
| 18:29:12 |
 Winter | @raitobezarius do you remember the context to https://git.lix.systems/lix-project/nixos-module/commit/a50986cfc71dfd60acaf55d31d1e3e05e9bdde6d ? | 18:49:04 |
| Winter | working on a semi-related change for nixpkgs and want to know if making nixos-option use config.nix.package would be bad/cause a bunch of rebuilds tm | 18:49:29 |
| raitobezarius | i think nixos-option code is deeply integrated with C++ API | 18:50:02 |
| raitobezarius | nix 2.18 seemed a reasonable pin at that time | 18:50:09 |
| raitobezarius | lix is not because of nixos-option developers are not striving for lix/nix C++ API compat | 18:50:29 |
| raitobezarius | * lix is not because of nixos-option developers are not striving for lix/nix C++ API compat (afaik) | 18:50:34 |
| raitobezarius | not even that, right? | 18:50:53 |
| raitobezarius | in the current semantics, people can manipulate Nix to observe very specific details of the impl | 18:51:04 |
| raitobezarius | if the same people change the interpreter innards and cause these observations to go wrong | 18:51:25 |
