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.
environment
is now a table rather than a list of tables. The parentframe of the current environment is
(get environment '%parent)
.When implementing an interpreter for Lumen, I noticed that the current
design makes it costly to store lexical environments. Each closure
would need to store
(cut environment)
, i.e. a clone of theenvironment array.
Performance is almost identical: the new design is less than 1% slower
on LuaJIT, Lua, and Node.
I'm not sure this PR is worth merging. I dislike that the name
"%parent" is now reserved. If someone tries to define a macro or
special form named "%parent", it will break.
The good part is
find-environment
andcurrent-environment
. Thesefunctions hide the details of Lumen's environment frames.
I'll submit this for now and think it over.
An idea to investigate: a
get-properties
function which takes anarbitrary object or function and returns a table. That'd make it easy
to annotate environment frames, e.g. marking a frame as "the toplevel
of the current function", or "the module toplevel," etc). It'd be
similar to elisp's
symbol-plist
, but for objects/functions ratherthan symbols.