Re: Let's talk about order of assignment

[Hao Wu <wuhao.wise@...>]

On Sun, Sep 14, 2014 at 2:25 PM, Coda Highland <chighland@gmail.com> wrote:
> On Sun, Sep 14, 2014 at 1:44 PM, Hao Wu <wuhao.wise@gmail.com> wrote:
>> On Sun, Sep 14, 2014 at 1:08 PM, Peter Melnichenko <mpeterval@gmail.com> wrote:
>>> 14.09.2014 21:33 "Thiago L." <fakedme@gmail.com>:
>>>
>>>
>>>>
>>>> For example:
>>>>
>>>> Lua 5.2.3  Copyright (C) 1994-2013 Lua.org, PUC-Rio
>>>> > setmetatable(_ENV, {__newindex = function(t,k,v) if k == "out" then
>>>> > io.write(v) end end}) out,out,out = "what","the","fuck"
>>>> fuckthewhat>
>>>>
>>>
>>
>> I am not sure this is right, but here is my thought:
>>
>>> More magic:
>>>
>>>> local a, a, a = 1, 2, 3; print(a)
>>> 3
>> In this case, the latter a is defined and overrode the previous one, thus used.
>>
>>>> b, b, b = 1, 2, 3; print(b)
>>> 1
>> the stack is popped in the reversed order so the first b is assigned
>> lastly (the same as the OP's example)
>>
>> Another test I did kinda proved my theory:
>>
>>> local a = 1; function foo() a = a+1; return a; end;
>>> local b,c,d = foo(), foo(), foo(); print(b,c,d)
>> 2   3  4
>>>local b,b,b=foo(),foo(),foo(); print(b)
>> 7
>>
>
> As mentioned earlier in the thread: The behavior of ambiguous multiple
> assignment is UNDEFINED. You can poke and speculate and figure out
> what THIS version of Lua does, but you shouldn't rely on it. EVER.
>
> It might change in the next version of Lua. It might be different in
> third-party implementations of Lua. It might (however unlikely) change
> if you build Lua on a different platform. It could fail entirely.
>
> So it's a little silly to sit here and iterate on different possible
> ways this might behave, because it's not required to be consistent (or
> even sane).

I agree with you that any assumption shouldn't be made for the order
of assignment, for now, but my point is that the result did make sense
if you think through how Lua usually works. It is undefined, yet
unsurprised. (besides, in the future version, this could be settled
and consistent, which might be the purpose of this thread).


>
> /s/ Adam
>