Re: Multiple assignments to the same variable

[Eike Decker <zet23t@...>]

2010/7/14 Robert Raschke <rtrlists@googlemail.com>:
>
> On Wed, Jul 14, 2010 at 10:53 AM, Eike Decker <zet23t@googlemail.com> wrote:
>>
>> 2010/7/14 Martijn van Buul (Ellips B.V.) <martijn.van.buul@ellips.nl>:
>> >> -----Original Message-----
>> >> From: lua-bounces@bazar2.conectiva.com.br [mailto:lua-
>> >> bounces@bazar2.conectiva.com.br] On Behalf Of Petite Abeille
>> >> Sent: Tuesday, July 13, 2010 9:21 PM
>> >> To: Lua list
>> >> Subject: Re: Multiple assignments to the same variable
>> >>
>> >>
>> >> On Jul 13, 2010, at 8:34 PM, Romulo wrote:
>> >>
>> >> >> Usually we consider that what the manual does not say is undefined.
>> >> >
>> >> > Or overlooked.
>> >>
>> >> Same difference.
>> >
>> > Is that so? The manual doesn't say in what direction statements are
>> > executed; all it says that they are executed sequentially. I always
>> > thought that it was implied that they are executed top-to-bottom,
>> > left to right, but now I realize it is undefined behavior since this
>> > is not explicitly mentioned in the manual.
>> >
>> > I guess I should start writing palindrome-programs, just in case
>> > lua 6 decides to start executing in reverse.
>> >
>>
>> This is very true... actually, if the assignment order on the left
>> side is undefined, the right side execution order is not helping if it
>> would be defined: If some metatables of the left side values are
>> calling functions because of the assignment, the program is already in
>> an "undefined" state.
>> I am not sure, but after pondering more and more on this issue, I come
>> to believe that the assignment order should be defined, both, left
>> side and right side order. Without such a statement, this could end up
>> in bugs that are hard to track down - and may end up in abolishing the
>> multiple assignment order at all.
>>
>> Greetings,
>> Eike
>
> No, please don't define the assignment order! It is a simultaneous
> assignment, after all. There is no order.
>
> If you want sequential assignment, you know how to get it.
>
> Similarly, I would argue having a defined order on the right hand side is
> just as bad, just as the order of parameter evaluation in function calls
> should not be defined.
>
> The reason for this is that most code is already serial enough. It helps a
> lot to structure code with independent calculations that are not ordered in
> any way. Especially when moving to an ever more parallel world of computing,
> little things like this are very valuable stepping stones in changing the
> way you think about coding.
>
> Maybe it might be worth specifically highlighting the non-ordering in the
> documentation. But that seems OTT.
>
> Robby
>
>

You propose nonderterministic behavior where it is no good (for a long time) - or at least I believe so, I am far away from being an expert on the field of multithreading. What would be the benefit of an unspecified order? There are no controls in Lua to go asynchronous and the VM is unable to call "more than one" function per time, even if it is an external C function. And on what nature should the VM decide the calling order then? Because the execution will be done in a serial manner since the VM is usually single threaded (and I don't see a way around this from my experience).

In my opinion, nondeterminism is making no practical sense here - Multiple assignments are actually pretty rare (compared to other stuff): Even if you could boost execution by n*100%, the effect in total would be 0. The only sense that the specification is undefined is that it is not regarded important at all - which I can understand: relying on a specific order in such an assignment is quite fragile. But I would appreciate if the ordering would be at least be guaranteed to be stable during the VM execution. Anything else could cause some really extremely painfully debugging ("Why is that code working here and not there, wtf?!").

But maybe I am wrong here - actually I wonder if Mike has stumbled upon this issue when implementing LuaJIT and what his opinion on this matter would be.

Greetings,

Eike