From 22b9e6ff092c531ee72037ff8f4c065eaff3b839 Mon Sep 17 00:00:00 2001 From: Adam Joseph Date: Tue, 25 Oct 2022 02:23:22 -0700 Subject: refactor(tvix/eval): administer antidote for poison 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 Signed-off-by: Adam Joseph Change-Id: Ib3309a47a7b31fa5bf10466bade0d876b76ae462 Reviewed-on: https://cl.tvl.fyi/c/depot/+/7089 Reviewed-by: tazjin Tested-by: BuildkiteCI Reviewed-by: flokli --- tvix/eval/docs/known-optimisation-potential.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'tvix/eval/docs') diff --git a/tvix/eval/docs/known-optimisation-potential.md b/tvix/eval/docs/known-optimisation-potential.md index 484ae271355d..e3015fc44b8a 100644 --- a/tvix/eval/docs/known-optimisation-potential.md +++ b/tvix/eval/docs/known-optimisation-potential.md @@ -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 -- cgit 1.4.1