| 11 Nov 2025 |
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 |
raitobezarius | what are the eval stability expectations we should offer here? | 18:51:35 |
raitobezarius | a real == for fns will make more things true, hence, if you rely on false-y values somewhere in your magic code, then we will destroy the stability as well here | 18:52:01 |
raitobezarius | the best thing i can muster/do is to take real world examples and analyze how much we are breaking vs. keeping working | 18:52:15 |
Winter | no it's a shell script now | 18:52:21 |
raitobezarius | i'm happy to do crater-style runs for that | 18:52:22 |
Winter | so i guess that was when it was in C++ | 18:52:29 |
raitobezarius | aaaaaaaaaaaaaaaaaaaaaah | 18:52:30 |
Winter | for god knows what reason | 18:52:32 |
Winter | lol | 18:52:32 |
Winter | ok thanks | 18:52:35 |
raitobezarius | :D | 18:52:39 |
Winter | i'll submit some PRs then ^^ | 18:52:41 |
raitobezarius | thanks! | 18:52:45 |
Taeer Bar-Yam | yeah, checking real-world cases is essential, but there is also something more pernicious about relying on false-y values than true-y values. if we throw out any notion of function equality, we break code that more reasonably relies on true-y values too. | 19:05:07 |
raitobezarius | Yeah, this is a tradeoff decision | 19:28:32 |
Rutile (Commentator2.0) feel free to ping | Li: am kinda curious: when will lix officially break bug compatibility and finally fix them? | 19:29:24 |
delroth | FYI: git.lix.systems might have some short unavailability in the next hour or so while I push a security update | 19:32:41 |
raitobezarius | In reply to @commentator2.0:elia.garden Li: am kinda curious: when will lix officially break bug compatibility and finally fix them? I don't know | 19:45:42 |
raitobezarius | All of this is very langver shaped and we don't have langver | 19:45:54 |
delroth | (done) | 19:46:49 |
| 12 Nov 2025 |
raitobezarius | pennae made progress on pointer equality and expanded all known cases we have in mind: https://gerrit.lix.systems/c/lix/+/4556/3/tests/functional2/lang/eq/in-pointer-equality.nix | 12:40:46 |
raitobezarius | We are planning to proceed with cl/4556 which is considered to be a breaking change. | 12:40:59 |
raitobezarius | The NaN behavior unsoundness is unfortunate but we will have to document it and accept it. | 12:41:14 |
raitobezarius | piegames if you have some time to spare, it'd be helpful for us if you can sign-off on https://gerrit.lix.systems/c/lix/+/4556 as well | 12:44:39 |
raitobezarius | https://wiki.lix.systems/books/lix-contributors/page/pointer-equality contains exposition info | 12:44:47 |
piegames | I'll try to have a look tomorrow | 13:14:27 |
K900 | I picked a nit | 13:15:27 |
niko ⚡️ | In reply to @raitobezarius:matrix.org The NaN behavior unsoundness is unfortunate but we will have to document it and accept it. Cursed not really serious idea - do pointer comparison as doubles, and make any object pointer which contains a nan, nan itself, and everything else not nan | 13:33:45 |