mdebray/tvl-depot
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

refactor(tvix/eval): administer antidote for poison

Browse source 
The codebase contains a lot of complexity and odd roundabout
handling for shadowing globals.  I'm pretty sure none of this is
necessary, and all of it disappears if you simply make the globals
part of the ordinary identifier resolution chain, with their own
scope up above the root scope.  Then the ordinary shadowing routines
do the right thing, and no special cases or new terminology are
required.

This commit does that.

Note by tazjin: This commit was originally abandoned when Adam decided
not to take away reviewer bandwidth for this at the time (eval was
still in a much earlier stage). As we've recently done some
significant refactoring of globals initialisation this came up again,
and it seems we can easily cover the use-cases of the poison tracking
in other ways now, so I've rebased, updated and resurrected the CL.

Co-Authored-By: Vincent Ambo <tazjin@tvl.su>
Signed-off-by: Adam Joseph <adam@westernsemico.com>
Change-Id: Ib3309a47a7b31fa5bf10466bade0d876b76ae462
Reviewed-on: https://cl.tvl.fyi/c/depot/+/7089
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Reviewed-by: flokli <flokli@flokli.de>
This commit is contained in:
Adam Joseph 2022-10-25 02:23:22 -07:00 • committed by tazjin
parent ab8486e5b8
commit 22b9e6ff09
8 changed files with 49 additions and 135 deletions
Download patch file Download diff file Expand all files Collapse all files

4
tvix/eval/docs/known-optimisation-potential.md
View file

@ -55,7 +55,7 @@ optimisations, but note the most important ones here.
When accessing identifiers like `builtins.foo`, the compiler should
not go through the trouble of setting up the attribute set on the
stack and accessing `foo` from it if it knows that the scope for
`builtins` is unpoisoned. The same optimisation can also be done
`builtins` is unshadowed. The same optimisation can also be done
for the other set operations like `builtins ? foo` and
`builtins.foo or alternative-implementation`.
@ -71,7 +71,7 @@ optimisations, but note the most important ones here.
a builtin application.
In case the compiler encounters a fully applied builtin (i.e.
no currying is occurring) and the `builtins` global is unpoisoned,
no currying is occurring) and the `builtins` global is unshadowed,
it could compile the equivalent operator bytecode instead: For
example, `builtins.add 20 22` would be compiled as `20 + 22`.
This would ensure that equivalent `builtins` can also benefit