Re: Explain?

[Rici Lake <lua@...>]

On 28-Oct-04, at 3:59 PM, Ben Sunshine-Hill wrote:

> 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.

Sure, you could do it, for example, by reordering stack assignments
within a scope to reflect the order of deletion.

My main point was that dead local detection is not as simple as
it looks at first sight (not that it is impossible), and I think
our subsequent discussion demonstrates that.

By the way, your example does not actually present any difficulties,
since the right-hand side of a local statement is evaluated before the
local scope starts:

 do
  2 --> local a [= 2]
  a + 3 / toss out a / --> local b [= a + 3]
  dosomething(b)
  b + 1 / toss out b / --> local c [= b + 1]
  doSomething(c)
 end

So a, b and c could all share a stack slot.

However, adding doSomething(a) after doSomething(b) would create the
issue. In that case c and a could share a slot, but b would need to be
in a lower slot. All doable, but...

:)

R,