Re: Explain?

[Ben Sunshine-Hill <sneftel@...>]

On Thu, 28 Oct 2004 13:54:29 -0500, Rici Lake <lua@ricilake.net> wrote:
> That's not quite accurate. The upvalue isn't closed until execution
> passes out of the scope in which the upvalue was declared.
> 
> In my example, "a" can be referenced by its known stack index
> anywhere within the scope of the "local a". Since the upvalue is
> not closed until that scope is exited, reusing a's stack slot
> (say, for the local "b" in my example) would change the value
> which would eventually be used by function "foo".
> 
> I don't know anyway of demonstrating that (aside from moral
> persuasion) other than by fabricating bytecode. But if you take
> a look at the luac -l output for the following fragment:
> 
>   local a = 7
>   function foo() return a end
>   a = 42
>   print(foo())
> 
> you will see that the assignment a=42 is not aware of the fact
> that a is an upvalue, whereas the function foo is.

Right. My point was, IF the compiler was rewritten to perform
aggressive lifetime optimization, upvalues would not present a
complication (since the end of the lifetime would represent an
implicit end-of-scope). The outer function may not be aware that a is
an upvalue, but the VM sure is, since it knows which upvalues to close
when leaving a scope.

Of course, this requires lifetimes to be nested.... that is, this
would still use three stack spaces (for the local variables)...

local a = 2
local b = a + 3
doSomething(b)
-- can't toss out "a" here, since "b" is still in scope
local c = b + 1
doSomething(c)

... which could conceivably cause inefficiency in the case of
upvalues. My main point was simply that the use of a variable in an
upvalue does not represent a "hidden" extension of the scope, only an
additional consideration when closing the scope.

Ben