| 1 Dec 2025 |
 raitobezarius | setMetaAttributes attrs { __eq = x; } ? | 12:30:00 |
 Qyriad | Yeah something like that | 12:30:14 |
| Qyriad | Which would return a new attrset obvi, not mutate | 12:30:23 |
| raitobezarius | ye | 12:30:32 |
 K900 | Y'all are actualyl just going to reinvent metatables aren't you | 12:30:43 |
| K900 | * Y'all are actually just going to reinvent metatables aren't you | 12:30:46 |
| raitobezarius | lua arc for lix letsgo | 12:30:57 |
| raitobezarius | personally idk yet | 12:31:12 |
| raitobezarius | the idea is interesting for sure | 12:31:16 |
| raitobezarius | and would provide a very nice way to escape from the funext mess | 12:31:25 |
| Qyriad | It 110% needs like, to be very well thought out so we don't trap ourselves, but we do think something in that direction is the right direction for Lix | 12:32:36 |
| K900 | I mean honestly I don't mind metatables | 12:33:07 |
| K900 | I do mind the rest of Lua | 12:33:12 |
| Qyriad | Same | 12:33:13 |
| K900 | But metatables are fine | 12:33:16 |
| Qyriad | Yes valid | 12:33:18 |
| Qyriad | It would also help the general problem of "attrsets represent packages you can enumerate but also other stuff and if you shove metadata into the set of packages now suddenly enumerating packages is more complicated" etc | 12:33:51 |
 niko ⚡️ | In reply to @qyriad:katesiria.org
scopedImport disables that caching Is the caching also on expressions themselves? Because if importing twice reuses the same eval, I’d expect let f = _: x: x; in f 0 == f 0 to also be true, at least based on vibes again, since applying a function feels equivalent to importing, for some definition of feeling | 12:34:31 |
| Qyriad | Function calls are not cached iwrc, but the attrs they return are? I think? | 12:36:12 |
| niko ⚡️ | I think this is where problems start for me personally | 12:39:55 |
| niko ⚡️ | Probably because of my biases, but I don’t have a problem with pointer comparison itself. The fact that I can’t tell just looking at code if the return value will be the same across calls is the most trippy personally | 12:40:55 |
| Qyriad | I mean that's unavoidable when we compare my pointer, that's why it's such a problem | 12:47:51 |
 piegames | In reply to @qyriad:katesiria.org
scopedImport disables that caching For now at least | 12:50:07 |
| niko ⚡️ | Just use pointer equality for the scope to decide on cache key /j | 12:50:52 |
 kloenk | Please don’t remind me of the horrors of the internals of the Linux kernel (they actually have structs that just contain an int so they can take a pointer to it as a unique value) | 12:58:33 |
| raitobezarius | that's why we can never use function pointer equality | 14:44:09 |
| raitobezarius | unless we have function semantical equality imho | 14:44:15 |
| raitobezarius | we don't want to let people develop a model of evaluation order, laziness semantics and so on | 14:44:28 |
| raitobezarius | (we want a rigorous model of course, but no one is allowed to tie their implementation to it) | 14:44:38 |
| raitobezarius | because funext only works via funptr equality, then funext must die | 14:44:52 |
