| 11 Dec 2025 |
 piegames | In reply to @charles:computer.surgery
i don't think they do:
nix-repl> "1" = 2
Added "1".
nix-repl> "1"
"1"
IMO that this syntax even exists in the first place is one of the many gotchas that happened because let bindings lazily reused attrset syntax just a bit too much (to be fair let binding used to be literally attrsets, which explains how it happened) | 22:28:55 |
 KFears (burnt out) | 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? Consistency, I think? I mean, I think this follows under the principle of least astonishment, that it's weird that attrsets can have arbitrary member names, but variables can't | 22:32:55 |
 ghpzin | If you consider attrset as dictionary / map equivalent in other languages, then it makes sense. | 22:36:01 |
| piegames | We already have an inconsistency for dynamic attributes and people seem to be fine | 22:36:59 |
| KFears (burnt out) | As mentioned before, I don't think static typing would work in general, but I'd like a bit more typing capabilities, because e.g. when you're implementing a module system, you have to create thin wrappers around basic types just so that you'd be able to combine them together into something bigger | 22:37:42 |
| KFears (burnt out) | e.g. I've seen code like this
float = lib.types.create {
name = "Float";
description = "floating point number";
check = builtins.isFloat;
merge = lib.options.merge.equal;
};
| 22:37:53 |
| KFears (burnt out) | It feels weird | 22:37:57 |
| piegames | In a let binding, you can't do {foo} = "bar" but you can do foo.{bar} = "baz" IIRC | 22:38:03 |
| piegames | Ugh, Matrix | 22:38:46 |
 hexa | markdown 😄 | 22:38:51 |
| piegames | Draw the rest of the owl I guess | 22:38:51 |
| hexa | ${foo} = "bar"
but you can do
foo.${bar} = "baz"
| 22:39:25 |
| KFears (burnt out) | I don't have a structured view of it, but in general, something at the intersection of modules and the type system strikes me as odd, and makes me feel like modules are a very "DIY" kind of thing that you have to reimplement from scratch, and I guess I'd be happy if the language could help with that, though I'm not sure where to take it | 22:39:29 |
| hexa | * can't do
${foo} = "bar"
but you can do
foo.${bar} = "baz"
| 22:39:34 |
 emily | overlays can be quite easily typed with row types. | 22:39:56 |
| KFears (burnt out) | Yeah, that's also weird... I'm not sure about it, like, it's convenient, but it feels weird, like I'd maybe expect a builtin that allows creating those kinds of arbitrarily-named attributes instead of it being a syntax thing | 22:41:57 |
| emily | e.g.
Overlay : Row -> Row -> Row -> Type
Overlay Final Prev Extra = {...Final} -> {...Prev} -> {...Extra}
data Overlays : Row -> Row -> Type where
nil : forall Final. Overlays Final {}
cons : forall Final Prev Extra. Overlay Final Prev Extra -> Overlays Final Prev -> Overlays Final (Prev // Extra)
addsFoo : forall Final Prev. Overlay Final Prev {foo : …}
addsFooUsingBar : forall FinalR Prev. Overlay (FinalR // {bar : …}) Prev {foo : …}
changesFoo : forall Final PrevR. Overlay Final (PrevR // {foo : …}) {foo : …}
changesFooUsingBar : forall FinalR PrevR. Overlay (FinalR // {bar : …}) (PrevR // {foo : …}) {foo : …}
(function to evaluate these left as an exercise)
| 22:48:44 |
| emily | I'd say it's not really that much different to typing TypeScript objects tbh | 22:49:49 |
 raitobezarius | ~~Now do IFDs~~ | 23:20:26 |
 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 |
