diff options
author | Vincent Ambo <mail@tazj.in> | 2022-08-26T23·16+0300 |
---|---|---|
committer | tazjin <tazjin@tvl.su> | 2022-09-03T21·55+0000 |
commit | f88d248f483af0cf1b83152367376b6b90893aac (patch) | |
tree | fc9c38978d8f261e195dde1c5995cbc031ee8f2f /users/sterni/mblog | |
parent | 0f06d0ca333d879f914fb6f8e0803a9d5acd3d03 (diff) |
feat(tvix/eval): implement runtime closure construction (OpClosure) r/4629
Implements the final bit of logic remaining for wiring up closures, which is the runtime construction of closure objects. When encountering an OpClosure, the VM walks through the bytecode collecting all the upvalue location operands (see commit introducing the OpCode::Data* variants for details) and stores the runtime values in the new closures upvalue vector. After that, the handling of the closure itself becomes functionally identical to that of lambdas. With this initial implementation of closures there are several large optimisation potentials available, the two most notable ones are: - Distinguish the runtime representation of lambdas and closures explicitly. - Detect and handle multiple-arity functions directly in the compiler. However, for both of these we should wait until we have appropriate benchmarking infrastructure in place. This is because our test implementations have shown that the complexity of either of these changes is quite significant, and we do not yet know if they really pay off. Change-Id: I077e977810fd5cb2b1ecd7f1a119e728025dd786 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6295 Tested-by: BuildkiteCI Reviewed-by: grfn <grfn@gws.fyi>
Diffstat (limited to 'users/sterni/mblog')
0 files changed, 0 insertions, 0 deletions