| 11 Dec 2025 |
 rosssmyth | Yeah, if you can define the types for all the common Nixpkgs utilities then let me know | 22:03:52 |
| rosssmyth | like | 22:04:07 |
| rosssmyth | overlays | 22:04:08 |
 piegames | In reply to @charles:computer.surgery
you need some syntax to "dereference" a string as if it were a variable Yes, that would indeed be needed | 22:21:54 |
 522 it/its ⛯ΘΔ | that and it doesn't really matter a ton because nix being a config language means there is no "runtime crash", really | 22:22:55 |
| 522 it/its ⛯ΘΔ | the difference between a type error and a runtime error is basically zero | 22:23:15 |
| rosssmyth | Also having to solve the types would just make eval slower | 22:24:30 |
| rosssmyth | 🎉 | 22:24:40 |
 KFears (burnt out) | In reply to @charles:computer.surgery
if i were designing a language from scratch and i wanted support for more or less arbitrary identifiers, i would have two kinds of identifiers:
- literal identifiers, like
foo, foo_bar, _foo123, etc; XID_Start followed by >=0 XID_Continue
- string identifiers, like
i"..." to use an arbitrary string of characters and escape sequences to construct an identifier
I think that sounds ideal | 22:24:50 |
| piegames | In reply to @piegames:flausch.social
Yes, that would indeed be needed But really the question is: why do we need arbitrary identifiers in the first place? | 22:26:32 |
| piegames | 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? | 22:27:27 |
| KFears (burnt out) | In reply to @helle:tacobelllabs.net
but I am just using this to demonstrate cases to worry about with UX and teaching, not so much as an actual thing to work on right now I think in the context of programming languages, it is common to have a section on "variables", and there it's explained that "you can give a name to the value, the name must start with an English letter and can contain numbers and - and _ | 22:27:33 |
| 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 |
