History

Vincent Ambo ccfb971dc5 fix(tvix/eval): correctly thread through dynamic upvalues This puts together the puzzle pieces for threading dynamic upvalues (that is, upvalues resolved from the `with`-stack) all the way through. Reading the test case enclosed in this commit and walking through it is recommended to understand what problem is being tackled here. In short, because the compiler can not statically know which with-scope a dynamic argument is resolved from it needs to lay the groundwork for resolving from all possible scopes. There are multiple different approaches to doing this. The approach chosen in this commit is that if a dynamic upvalue is detected, the compiler will emit instructions to close over this dynamic value in all enclosing lambda contexts. It uses a new instruction for this that will leave around a sentinel value in case an identifier could not be resolved, and wire the location of this found value (or sentinel) up through the upvalues to the next level of nesting. In this tradeoff, tvix potentially closes over more upvalues than are needed (but in practice, how often do people create really deep `with`-stacks? and in this kind of code situation? maybe we should even warn for this!) but avoids keeping the entire attribute sets themselves around. Looking at the test case, each surrounding closure will close over all dynamic identifiers that are referenced later on visible to it, but only the last one for each identifier will actually end up being used. This also covers our bases for an additional edge-case this creates, in which an identifier potentially resolves to a dynamic upvalue and to a dynamic value within the function's own scope (again, would anyone really do this?) by introducing a resolution instruction for that particular case. There is likely some potential for cleaning up this code which is quite ugly in some parts, but as this implementation is now carefully calibrated to work I decided it is time to commit it and clean it up in subsequent commits. Change-Id: Ib701e3e6da39bd2c95938d1384036ff4f9fb3749 Reviewed-on: https://cl.tvl.fyi/c/depot/+/6322 Tested-by: BuildkiteCI Reviewed-by: sterni <sternenseemann@systemli.org>		2022-09-06 07:45:43 +00:00
..
.vscode	feat(tvix): set up cargo rust project	2022-01-06 15:38:52 +00:00
docs	style: format entire depot with nixpkgs-fmt	2022-01-31 16:11:53 +00:00
eval	fix(tvix/eval): correctly thread through dynamic upvalues	2022-09-06 07:45:43 +00:00
nix_cli	chore(tvix/nix_cli): add default.nix	2022-08-30 11:03:48 +00:00
proto	style: format entire depot with nixpkgs-fmt	2022-01-31 16:11:53 +00:00
.envrc	feat(tvix): set up cargo rust project	2022-01-06 15:38:52 +00:00
.gitignore	feat(tvix): set up cargo rust project	2022-01-06 15:38:52 +00:00
LICENSE	chore(tvix): Bootstrap Tvix folder	2021-03-27 00:09:49 +00:00
OWNERS	chore(tvix): Bootstrap Tvix folder	2021-03-27 00:09:49 +00:00
README.md	chore(tvix): Bootstrap Tvix folder	2021-03-27 00:09:49 +00:00

README.md

Tvix

For more information about Tvix, contact one of the project owners. We are interested in people who would like to help us review designs, brainstorm and describe requirements that we may not yet have considered.

License structure

All code implemented for Tvix is licensed under the GPL-3.0, with the exception of the protocol buffer definitions used for communication between services which are available under a more permissive license (MIT).

The idea behind this structure is that any direct usage of our code (e.g. linking to it, embedding the evaluator, etc.) will fall under the terms of the GPL3, but users are free to implement their own components speaking these protocols under the terms of the MIT license.