| 11 Dec 2025 |
rosssmyth | I think there's a Gleam backend for Nix. Unsure how maintained it is. | 21:34:50 |
Rutile (Commentator2.0) feel free to ping | In reply to @rosssmyth:matrix.org My overall biggest complaint with the nix lang is that lists should be separated with commas so that spaces are not quite as overloaded What about scala sytle no brackets at all and just :: between the elements? :D i.e.
a :: b :: c /j | 21:36:04 |
helle (just a stray cat girl) | noooooo | 21:36:15 |
helle (just a stray cat girl) | wrote enough Scala, to go nooooo | 21:36:20 |
helle (just a stray cat girl) | (we may have written in so many different languages at this point) | 21:36:35 |
Rutile (Commentator2.0) feel free to ping | Oh wait, nvm :: was just the (right hand associated) prepend operator, one must end it with a :: Nil | 21:37:12 |
Rutile (Commentator2.0) feel free to ping | Can nixlang2 get static typing at least?, the currrent one really feels like another javascript but for config instead of websites | 21:50:33 |
K900 | My galaxy brain take is that actually statically typing Nix is basically impossible to make good | 21:54:17 |
K900 | You need to do whole program inference, typescript style | 21:54:45 |
K900 | And probably refinement typing too | 21:54:51 |
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 |