lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



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