docs(tvix/eval): builtins.add is not equivalent to +

While it is in the given example, i.e. for integer addition, to claim
that they are equivalent is a bit misleading: builtins.add is less
overloaded than +, i.e. builtins.add "foo" "bar" will fail whereas
"foo" + "bar" performs string concatenation.

Change-Id: Ib52d530d1ab289b367565b286f06a76dd518d4fb
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7929
Autosubmit: sterni <sternenseemann@systemli.org>
Reviewed-by: flokli <flokli@flokli.de>
Tested-by: BuildkiteCI
This commit is contained in:
sterni 2023-01-25 14:39:24 +01:00 committed by clbot
parent 669496f0ba
commit 8a8325fb9d

View file

@ -64,8 +64,8 @@ optimisations, but note the most important ones here.
* Inline fully applied builtins with equivalent operators [medium] * Inline fully applied builtins with equivalent operators [medium]
Some `builtins` have equivalent operators, e.g. `builtins.add` Some `builtins` have equivalent operators, e.g. `builtins.sub`
corresponds to the `+` operator, `builtins.hasAttr` to the `?` corresponds to the `-` operator, `builtins.hasAttr` to the `?`
operator etc. These operators additionally compile to a primitive operator etc. These operators additionally compile to a primitive
VM opcode, so they should be just as cheap (if not cheaper) as VM opcode, so they should be just as cheap (if not cheaper) as
a builtin application. a builtin application.
@ -73,7 +73,7 @@ optimisations, but note the most important ones here.
In case the compiler encounters a fully applied builtin (i.e. In case the compiler encounters a fully applied builtin (i.e.
no currying is occurring) and the `builtins` global is unshadowed, no currying is occurring) and the `builtins` global is unshadowed,
it could compile the equivalent operator bytecode instead: For it could compile the equivalent operator bytecode instead: For
example, `builtins.add 20 22` would be compiled as `20 + 22`. example, `builtins.sub 20 22` would be compiled as `20 - 22`.
This would ensure that equivalent `builtins` can also benefit This would ensure that equivalent `builtins` can also benefit
from special optimisations we may implement for certain operators from special optimisations we may implement for certain operators
(in the absence of currying). E.g. we could optimise access (in the absence of currying). E.g. we could optimise access