[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: bug report: LUA compiler glitch
- From: David Kastrup <dak@...>
- Date: Wed, 10 Aug 2011 09:34:22 +0200
Lars Doelle <email@example.com> writes:
>> From: Mike Pall <firstname.lastname@example.org>
>>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
>>But it neither guarantees a particular evaluation order for the
>>right-hand side, nor a particular assignment order for the
> 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
> 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.