<pie_>
id like to report an inconsistency :P , there doesnt seem to be a way to use ${something} in a rec on the right side of an attr assignment, but you can on the left
<ekleog>
you don't need the ${} on the right
<ekleog>
${} is only for interpolation
<ekleog>
on the right it's parsed as an expression, so you can't interpolate, while on the left it's parsed as a string (which might be surprising given it's not actually quoted, but it is)
<infinisil>
pie_: I guess the thing you're complaining about is how you can define variables with invalid names, but not reference them. Hasn't been a problem for me in practice though
<infinisil>
Hmm
<pie_>
ekleog, what if i speficy a functions name as a string? i can then not call the function
<pie_>
because i dont have a reference to its parent scope, unless i do some messing around with passing it back to itself probably
<infinisil>
> let a = "foa"; in rec { ${a} = 10; b = foa; }
<{^_^}>
{ b = <CODE>; foa = 10; }
<infinisil>
> :p let a = "foa"; in rec { ${a} = 10; b = foa; }
<{^_^}>
undefined variable 'foa' at (string):253:40
<pie_>
yeah, for some reason i thought it doesnt have everything
<infinisil>
Now I feel like making a list of things I'd change on the language :D
<infinisil>
This would include
<infinisil>
- Getting rid of with ..; syntax
<infinisil>
- Making ${".."} a dynamic attribute
<infinisil>
- Allowing pattern matching in function arguments, like attrs@{ baz@{ foo, ... }, bar, ... }:
<pie_>
also either force ${} to be always quoted or make it a usable in an expression ;P
<pie_>
* :P
<infinisil>
I'm not sure if this is doable tbh
<infinisil>
The usable in expression thing
<pie_>
alternatively (probably a horrible idea): a way to refer to the current scope
<pie_>
this.${thing}
<infinisil>
I also feel like this would be problematic to implement, seems like that would conflict with purity
<infinisil>
Ah I guess it could be `builtins.unsafeGetScope "<name>"`
<infinisil>
But it does sound like a bad idea and a code smell
<pie_>
yeah i guess it could conflict with purity. alternatively youd be EVEN MOAR PURE because now the structure of your code is also an input ;P
<infinisil>
That makes it less pure!
<pie_>
i think the easy solution would be to require quotes always. docs say you can only leave it unquoted if its a single substitution anyway. at least that way one wouldnt get confused by it *looking* like it might be usable on a non-left-side
<pie_>
well, whatever
<pie_>
infinisil, i also want something for "mergeable" defaults but that doesnt sound too clean either
<infinisil>
What's that?
<pie_>
when i was complaining the other day about not being able to pass defaults through with @args
<pie_>
actually....thats probably orthogonal
<pie_>
ok, sorry, im distracted.
<infinisil>
Ah right, yeah that seems a bit problematic
<infinisil>
Haskell doesn't have this problem because there you can't have defaults
<infinisil>
> (args@{ a ? 1 }: args) {}
<{^_^}>
{ }
<infinisil>
I guess it would actually make sense to get rid of the ability to know whether a was passed or not
<infinisil>
Can always do
<pie_>
tldr the mergable defaults stuff is something something the argument has a default set, and i pass a set, the attributes of which should override the defaults
<infinisil>
> (args@{ a ? 1 }: args.a == 1) {}
<{^_^}>
attribute 'a' missing, at (string):253:18
<infinisil>
(assuming args would get the a)
<pie_>
so default: {a = 1; b = 2}, args I pass {a = 3;} I get: {a = 3; b = 2;}, this works fine with // of course, at usage sites
Synthetica has quit [Quit: Connection closed for inactivity]
Synthetica has joined #nix-lang
ddellacosta has joined #nix-lang
ddellacosta has quit [Ping timeout: 246 seconds]
Synthetica has quit [Quit: Connection closed for inactivity]