Added a test for lexical scoping. #34
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added a test for lexical scoping and a way that it could be theoretically implemented. The test is equivalent to the following Scheme code:
(display (((lambda (x) (lambda () x)) 3141592)))(which should display 3141592). Running the test on the current branch errors out when it's unable to find the variablex.But the above approach (which is also in this PR) to adding lexical scoping might be undesirable because it means that some functions in the Scheme registry can no longer be defined using only the DSL (using a
{"closure", params, body}triple). Instead they would have to be defined using Elixir functions/closures (i.e.{"closure", fn -> ... end}).Another approach to implementing Scheme closures in a way that passes the above test could be to add a third field to the "closure" structure to also store
env(at the point when thelambdawas evaluated) in. In this case, the body of the closure would be evaluated in an environment formed by taking the environment stored in the closure (instead of the environment at the point of application) and adding bindings from the closure's parameters to the closure's arguments.But this second approach might be problematic when defining some of the functions in the Scheme registry because it would then require that there be a way to express recursive bindings in the DSL itself (since the binding
nthdoes not exist during its definition). Something like aletrecordefineconstruct that allows a definition to refer to itself. In the compiler, I essentially took the latter approach but withdefinerenamed tofunction.Another idea that comes to mind: if the functions that are currently defined (using the DSL) in the environment could somehow be moved/prepended to the actual DSL program, then it might make it easier to compile everything. The Scheme compiler would then simply be able to take an expression (or list of them) containing the actual program and definitions of
map,take, etc, and convert them to C without needing to process an environment. For example, like:anoma-local-domain/lib/examples/e_transpile.ex
Lines 23 to 32 in 123af59