| 11 Dec 2025 |
 Charles | Box<dyn Any> | 23:25:25 |
 rosssmyth | Sure, row polymorphism works but in reality a type theory that uses that would be really poor in practice | 23:43:27 |
| rosssmyth | And some types may be infinitely large | 23:44:50 |
| rosssmyth | * Sure, row polymorphism works but in reality a type theory that uses that would be really poor to use in practice | 23:45:38 |
| 12 Dec 2025 |
 emily | because of recursive object types? sure, that is just the problem any OOP language has to deal with really | 00:47:11 |
| emily | I don't think there are many challenges for the Nix case here that TypeScript does not already have to deal with (admittedly it sacrifices soundness) | 00:47:27 |
| emily | the Nix attrset typing case is also not far off what 1ML does FWIW | 00:47:58 |
| emily | (I do think there are things that would make typing existing Nixpkgs idioms somewhat painful, but I don't think the basic attrset system is the big issue there) | 00:50:34 |
|  whispers (it/fae) changed their profile picture. | 04:51:24 |
 aloisw | In reply to @commentator2.0:elia.garden
What about scala sytle no brackets at all and just :: between the elements? :D
i.e.
a :: b :: c
/j That looks like something that only works well when the lists are linked lists. | 06:35:56 |
| aloisw | In reply to @piegames:flausch.social
We need them for attrsets obviously, and a way to access those, but we already have that. Having a "foo bar" key is important, but having a variable named "foo bar" in a let binding? What for? I agree that having the variable in the let binding may not be that important in itself, but there's also the module-like use case of attrsets and you kinda need identifiers to be able to represent all keys to not have weird edge cases (think "with/inherit/let open … in (or whatever it may be called) only works under these specific conditions on the keys"). | 06:40:22 |
