infinisil changed the topic of #nix-lang to: Channel for discussing Nix as a language - https://nixos.org/nix/manual/#chap-writing-nix-expressions - Logs: https://logs.nix.samueldr.com/nix-lang/
rajivr has joined #nix-lang
niksnut has quit [Ping timeout: 264 seconds]
niksnut has joined #nix-lang
__monty__ has joined #nix-lang
<Profpatsch> I … wow, … what,,
<Profpatsch> let foo = "static"; varname = "foo"; x = { ${varname} = "dynamic"; body = foo; }; in x.body
<Profpatsch> "static"
<Profpatsch> > let foo = "static"; varname = "foo"; x = { ${varname} = "dynamic"; body = foo; }; in x.body
<{^_^}> "static"
<sterni> Profpatsch: at least your set was non recursive
<sterni> at least it should work with lib.fix right....
<Profpatsch> I think let and rec are the same internally, so I wanted to check it misbehaves the same with a let
<srhb> I don't see any misbehaviour. What am I missing? Did you mean to include `rec` somewhere?
<Profpatsch> srhb: x.body should be using the dynamic foo assigned via varname
<Profpatsch> instead of the foo coming from the let binding
<Profpatsch> So the result should be "dynamic" not "static"
<Profpatsch> At least that’s what I am expecting
<srhb> I'm really not sure why you're expecting that. Let's see. x.body is the `foo` defined in the let... foo = "static"
<srhb> Everything else is superfluous
<Profpatsch> srhb: what?
<srhb> x.body = foo, right?
<srhb> And foo = static
<srhb> Sorry, foo = "static"
<Profpatsch> yeah, but let definitions are self-recursive
<Profpatsch> Oh, wait
<Profpatsch> It would have to be body = x.foo
<srhb> Yes.
<Profpatsch> But with rec it’s different
<Profpatsch> Because you don’t give a name to the current scoe
<srhb> Right, the attrs are all in scope.
<Profpatsch> I think that’s yet another reason to ban rec :P
<srhb> You're thinking about how _this_ is utterly confusing? If so, I agree:
<srhb> > let foo = "static"; varname = "foo"; x = rec { ${varname} = "dynamic"; body = foo; }; in x.body
<{^_^}> "static"
<srhb> Clearly _that_ should be "dynamic" :P
<srhb> > let foo = "static"; bar = "foo"; x = rec { ${varname} = "dynamic"; body = foo; }; in x.bar
<{^_^}> undefined variable 'varname' at (string):472:46
<srhb> Oops
<srhb> I didn't mean to paste that here :)
<infinisil> > let foo = "static"; varname = "foo"; x = let { ${varname} = "dynamic"; body = foo; }; in x
<{^_^}> "static"
<srhb> Excuse me
<srhb> oh
<srhb> I missed the let xD
<srhb> That's truly trolly.
<infinisil> :P
__monty__ has quit [Quit: leaving]
<sterni> why how what
rajivr has quit [Quit: Connection closed for inactivity]
<infinisil> Wait so what's the reason again for not having a `builtins.catch`?
<infinisil> Yes there's the problem of eval order influencing which error is thrown
<infinisil> But: Eval order is deterministic in Nix
<sterni> I also didn't get what the comment about evaluation purity was about
<sterni> I think the question is whether eval order is not only deterministic but also defined, i. e. stable?
<sterni> otherwise future nix releases could break a catch construct of course
<infinisil> Well it has never changed before
<infinisil> Afaik at least
<infinisil> I don't know how it *could* be changed
<infinisil> Maybe parallel evaluation
<infinisil> tazjin: Didn't you recently explore using GHC's evaluator?
<tazjin> yes
<tazjin> But I'm also in a Czech bar in Egypt rn and not sober enough to talk about it :p
<sterni> seems to me the purity question is only about eval order: https://github.com/NixOS/nix/pull/1000#issuecomment-235872787
<sterni> catch is not pure for a definition of independent of eval order
<sterni> unsure if eelco's comment is from a perspective of eval order is indeterministic or eval order may change in the future
<Profpatsch> exceptions in a lazy language are a garbage fest
<Profpatsch> better not depend on anything, especially not eval order
<Profpatsch> like, tryEval itself is already highly dubious and should be banned really
<Profpatsch> this is a slippery slope if I’ve seen one
<ekleog> exception monad or gtfo
V has joined #nix-lang
<sterni> I guess tryEval is somewhat fine as it only catches user generated errors anyways and doesn't tell you anything about it
<sterni> but honestly that is something you can also emulate in pure nix without tryEval if you need to
<sterni> but then you have yants probably :p
mpickering has quit [Read error: Connection reset by peer]
mpickering has joined #nix-lang
<infinisil> sterni: You can't practically, because then every code path along the way needs to be made to work that way
<sterni> infinisil: yeah it's definitely not viable for real world usage (nixpkgs)
<Profpatsch> Unless languages like rust just make it viable
<Profpatsch> And everybody in the nooooo you can’t just return errors like a normal person crying nerd camp is taken aback by haha, Result<a, err> go brrrrrrr
<Profpatsch> “but it’s so inefficient”
<infinisil> Profpatsch: Meanwhile we have a clustefuck of error handling in Haskell hah
<ekleog> Must say I love this exchange <3