Re: bug report: LUA compiler glitch

[David Kastrup <dak@...>]

Lars Doelle <lars.doelle@on-line.de> writes:

>> From: Mike Pall <mikelu-1108@mike.de>
>>Ross Andrews wrote:
>>> By "order of assignment is undefined", does it mean that the order in which
>>> values are put in variables is undefined, or the order in which the
>>> right-hand side is evaluated is undefined?
>
>>Actually both. The parallel assignment statement only guarantees
>>that all expressions on the right-hand side are evaluated before
>>any of the assignments are made. See section 2.4.3 in the Lua 5.1
>>manual.
>
>>But it neither guarantees a particular evaluation order for the
>>right-hand side, nor a particular assignment order for the
>>left-hand side.
>
> Hi,
>
> I like to emphasize a point, and this is the definition of pairwise
> binding, which is not covered by any of the responses.
>
> Say one has ''function foo(a,a) return a end'' calling ''foo(1,2)'' will
> return correctly ''2''.

This just depends on the formal parameters being declared in sequential
order, so the second parameter shadows the first.

When you write
a,a = 1,2 return a
there is no shadowing involved.  The order of assignment is undefined.

When you write instead
local a,a = 1,2 return a
the second local declaration shadows the first, and the result is indeed
2.

> While both variables have the same name, they are different, really,

Not when you write a,a = 1,2.  That is the same variable twice.  With
local a,a = 1,2 you get two different variables.

> and the assignments should be pairwise like in the function call.

What makes you think they aren't?

> The glitch confuses both variables, not only breaking the order of
> side effects (sorry, if disagree I here, that leaving this undefined
> is not good thing) but also the order binding in variable
> introduction.  If pairing in binding is additionally undefined, then
> please what is?

No new binding gets declared without writing local.

-- 
David Kastrup