Companion thread to Cursed Nix Koans.
Why does redefining
__mul work but not
Spoilers: #nixos on 2019-11-04 — irc logs
I’m not sure why dealing with strings matters. You should be able to write something like
__add = x: y: if builtins.isString x then # do something string-y else # do something numeric ;
Or I guess the other question is why have
__add at all since it’s apparently not used.
I’m guessing it’s something about how the parser works and not the evaluation semantics. (If that makes any sense?)
This operator seems to be defined different from the other ones
(sidenote: What’s a CONCAT?)
So after a little digging I found https://github.com/NixOS/nix/blob/e012384fe99bd7d229fffa78f890d3ede915709b/src/libexpr/eval.cc#L1377
So…the semantics of + are hardcoded in the parser? Does __add even get used?
I’m just collecting this stuff
Ok maybe me messing around with spoiler tags is kind of pointless
Oh no, is this planned for removal? https://github.com/NixOS/nix/issues/861
Huh. Trying to figure this stuff out is pretty educational.
Yeah I dug around in the parser already and found that. I’m amused that
+ by default goes through something called “string concat”, which itself checks if the first arg is numeric instead. But this is why I asked why we have
__add at all since AFAICT it’s never called anywhere.
In any case, operator overloading is cute but I wish it worked like
__functor, i.e. that you could define
__mul in a set and it would be invoked if that set were used as the LHS of the operator.
I was hoping to do a variant on this that used
> instead by defining
__lessThan but it turns out that no matter how you define
__lessThan, an expression of the form
a > b > c is a syntax error. I’m rather curious why this is so; obviously with the default implementation it would be a type error (
true > x shouldn’t ever work) but I don’t see a reason for it to be syntactically prohibited.