Re: a new proposal for environments

[Peter Cawley <lua@...>]

On Fri, Feb 26, 2010 at 1:37 PM, steve donovan
<steve.j.donovan@gmail.com> wrote:
> On Fri, Feb 26, 2010 at 3:32 PM, Roberto Ierusalimschy
> <roberto@inf.puc-rio.br> wrote:
>> This can be done through the debug API (with a huge overhead).
>
> Yes, I had it do it like this when exploring the 'incremental
> compilation' pattern. When recompiling a function, I had to fake
> access to the 'upvalues'

At least with debug.upvaluejoin in 5.2, this overhead can can be
addressed entirely at compile-time, with no overhead once compiled. To
give "some code" access to all locals as upvalues:
1) Use the debug API to traverse the call stack and pull out the list
of locals at each level (or just the list of locals at the levels
you're interested in).
2) Do loadstring("local loc1, loc2, loc3, ...; return function() some
code end")() where loc1 etc. are the names of the locals you
identified.
3) Inspect which upvalues are used in the resulting function, and use
debug.upvaluejoin to convert these faux upvalues in resulting function
into the real ones you identified in the call stack.

Practical note: If in step 1, you identify more than ~250 potential
upvalues, then you will run into a problem in step 2. Hence it is more
robust to perform a quick lex of the "some code" to identify exactly
which upvalues you need.