Re: Redefining locals

[Rici Lake <lua@...>]

On 11-Nov-04, at 9:32 PM, Matt Hellige wrote:

> I thinks that 'local a, a' should remain valid, but I think the
> meaning should change... Instead of defining two separate slots, I
> think it should define one slot and then assign to it... I guess
> that's a silly distinction in this case, but it's important in other
> cases...

There was some discussion about this a couple of months ago on
this list, too, I think. The point is that the assignment of
locals to stack slots is essentially invisible to a program
unless the debug library is being used. (With the caveat that
the both of the values are referenced from the stack and
therefore cannot be garbage collected until the block is exited;
however, the precise moment of garbage collection is not defined
in the language's semantics either.)

A (more) optimizing compiler should be free to change:
  local a, a = foo(), bar()
into:
  local a = foo()
  a = bar()

This cannot produce a change in the defined semantics of the language.

However, trying to do this in general is (as usual) Not As Simple As It 
Looks.
For example, how would you deal with:

  local a, b, a, a, c = returns_some_number_of_values()

Five stack slots need to be set aside for the function's return values. 
It
is true that the stack could be reordered and compressed afterwards, 
but is
it worth the extra VM instructions?

In addition, in the particular case (which Alex Bilyk doesn't like but I
use a lot) of

  local _, _, capture = string.find(str, pattern)

It is actually quite handy that both _ are on the stack while debugging.
(And since they are both just numbers, there is little value in getting
rid of one of them; it will go out of scope soon enough anyway and
"popping" doesn't cost anything (since it never really happens).

I plan to add an "overridden local" test to the next version of 
LuaParse,
when I have a chance to work on that again. (Patches, as they say, are
welcome.)

Rici