Re: implementation of lexical scoping

[ramsdell@... (John D. Ramsdell)]

> This mail explains the general idea we used to implement lexical
> scoping in Lua. Sorry for the delay in answering several questions
> about this.

Thanks.  This is all very interesting.  It appears that the algorithm
you describe adds a cost to every closure creation, a cost borne at
runtime.  The alternative is to perform a two-pass compilation when
generating bytecode, and during the first pass, mark local variables
accessed by nested functions as requiring heap allocation.  The second
pass can generate efficient closures that allocate most of their local
variables on the stack.

It's a classic compile-time vs. runtime trade-off.  It will be
interesting to see the performance results.  For most scripts, all
closure creation will be done when the bytecode is loaded, so I'm
guessing the overhead in time will be small.  I hope the open
references list does not take up too much space.

John

Roberto Ierusalimschy <rieru@delirius.cs.uiuc.edu> writes:

> The main problem for implementing lexical scoping in Lua is that,
> when we first see a variable, we do not know whether it will be used
> by an inner function, and therefore whether it may have to outlive
> the function that created it (as I do not know a better name for
> them, I will keep calling a local variable that is used by an inner
> function an "upvalue").

> The last cost is that, when creating a new closure with open
> references (the most common case), we must insert it in its proper
> place in the list of open closures.