Documentation for multiple assignment fails to mention order

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Documentation for multiple assignment fails to mention order

Niccolo Medici
The documentation for multiple assignment (section "3.3.3 –
Assignment" in the manual) doesn't mention the fact the assignment is
*not* carried out in order. That is, that the assignment isn't carried
out from left to right. E.g., given the code:

    t.one, t.two = 1, 2

then the programmer is wrong to assume that t.one is assigned before t.two.

This matters when the assignment triggers a function (i.e., when 't'
has a metatable with __newindex) and when the order of calling the
functions matter.

Here's complete code to demonstrate the problem:

    local t = setmetatable({}, {
      __newindex = function(self, k, v)
        print("Assigning to key " .. k)
      end,
    })

    t.one, t.two = 1, 2

Running the this program produces this surprising output:

    Assigning to key two
    Assigning to key one

BTW, is it guaranteed that the assignment order goes from RIGHT to
LEFT (I verified this in Lua 5.1, 5.2, 5.3, LuaJIT), or is it
"undefined behavior"?

Reply | Threaded
Open this post in threaded view
|

Re: Documentation for multiple assignment fails to mention order

Luiz Henrique de Figueiredo
> BTW, is it guaranteed that the assignment order goes from RIGHT to
> LEFT (I verified this in Lua 5.1, 5.2, 5.3, LuaJIT), or is it
> "undefined behavior"?

It is not undefined behavior at all.

The manual does not mention the order of individual assignments in a
multiple because it is an implementation detail. This allows us to
change the implementation without changing the semantics.

It is like in C, which does not specify the order of evaluation of
expressions in argument lists in function calls.

The semantics of multiple assignment in Lua is explained in the manual:

        The assignment statement first evaluates all its expressions and only
        then the assignments are performed.

and is followed by this example:

        Thus the code
                i = 3
                i, a[i] = i+1, 20
        sets a[3] to 20, without affecting a[4] because the i in a[i] is
        evaluated (to 3) before it is assigned 4.

Again, the manual does not specify the order of evaluation of the expressions.

Reply | Threaded
Open this post in threaded view
|

Re: Documentation for multiple assignment fails to mention order

Niccolo Medici
On 7/25/16, Luiz Henrique de Figueiredo <[hidden email]> wrote:

> > The documentation for multiple assignment (section "3.3.3 –
> > Assignment" in the manual) doesn't mention the fact the assignment is
> > *not* carried out in order.
> > <snip>
> > BTW, is it guaranteed that the assignment order goes from RIGHT to
> > LEFT (I verified this in Lua 5.1, 5.2, 5.3, LuaJIT), or is it
> > "undefined behavior"?
>
> It is not undefined behavior at all.
> <snip>
> It is like in C, which does not specify the order of evaluation of
> expressions in argument lists in function calls.

You actually prove my point here. The C standard *does* say that the
order is "unspecified". It doesn't keep mum and let programmers
throughout the world stumble on unspecified behavior. No! It *states*
that the behavior is unspecified so that programmer don't rely on what
their compiler does. That's what I'm asking for. Let me quote:

The C standard: [1]

    6.5.2.2 Function calls
    [...]
    Semantics
    [...]
    10. The order of evaluation of the function designator,
        the actual arguments, and subexpressions withing the
        actual arguments is unspecified

C was designed by Dennis Ritchie and this is what he writes in his
book (together with Kernighan), "The C Programming Language", in the
"Reference Manual" section:

    A7.3.2 Function Calls
    [...]
    The order of evaluation of arguments is unspecified.

So, as you see, logicians think that unspecified behavior ought to be stated.

>
> The manual does not mention the order of individual assignments in a
> multiple because it is an implementation detail. This allows us to
> change the implementation without changing the semantics.

You give two reasons.

First, you say "it's implementation detail". That's no reason to not
state that it's "unspecified behavior".

Second, you say "this allows us to change the implementation". Again:
that's no reason to not state that it's "unspecified behavior". How
can stating "The order in which the assignments are carried out, and
the order of evaluation of the expressions, is unspecified" can
inhibit your option to change this behavior in the future?

>
> Again, the manual does not specify the order of
> evaluation of the expressions.

And that's wrong too.

When you don't state that something is unspecified, programmers may
rely on some behavior they see in their compiler, behavior that to
them seem natural and obvious. When they don't see the issue mentioned
in the manual it enforces their view that the behavior they deem
obvious is the "correct" one (they don't actually need enforcement,
though, as they're convinced from the start).

Then, when the implementation changes, their programs break. This puts
a damper on your "This allows us to change the implementation without
changing the semantics". Incidentally, let's consider the word
"semantics". You would rebuke me if I relied on the order of the
evaluation/assignment. Why? Because what I've done has meaning.
Meaning *is* semantics. Interestingly, note how the C committee puts
that notice under a section titled "Semantics" (see my quote). Keeping
mum about it doesn't mean it's not semantics. No. It only means my
program is going to break in the future.

[1] www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

Reply | Threaded
Open this post in threaded view
|

Re: Documentation for multiple assignment fails to mention order

Dirk Laurie-2
2016-07-25 18:28 GMT+02:00 Niccolo Medici <[hidden email]>:

> On 7/25/16, Luiz Henrique de Figueiredo <[hidden email]> wrote:
>> > The documentation for multiple assignment (section "3.3.3 –
>> > Assignment" in the manual) doesn't mention the fact the assignment is
>> > *not* carried out in order.
>> > <snip>
>> > BTW, is it guaranteed that the assignment order goes from RIGHT to
>> > LEFT (I verified this in Lua 5.1, 5.2, 5.3, LuaJIT), or is it
>> > "undefined behavior"?
>>
>> It is not undefined behavior at all.
>> <snip>
>> It is like in C, which does not specify the order of evaluation of
>> expressions in argument lists in function calls.

> You actually prove my point here.
...
> You give two reasons.
>
> First, you say "it's implementation detail". That's no reason to not
> state that it's "unspecified behavior".
>
> Second, you say "this allows us to change the implementation". Again:
> that's no reason to not state that it's "unspecified behavior".
...
> And that's wrong too.

I am not easily shocked, but this response by an OP to a reply by
a member of the Lua team is some of the worst trolling I have ever
seen on any mailing list.

Reply | Threaded
Open this post in threaded view
|

Re: Documentation for multiple assignment fails to mention order

GrayFace-2
On Пн 25.07.16 23:45, Dirk Laurie wrote:

> 2016-07-25 18:28 GMT+02:00 Niccolo Medici <[hidden email]>:
>> On 7/25/16, Luiz Henrique de Figueiredo <[hidden email]> wrote:
>>>> The documentation for multiple assignment (section "3.3.3 –
>>>> Assignment" in the manual) doesn't mention the fact the assignment is
>>>> *not* carried out in order.
>>>> <snip>
>>>> BTW, is it guaranteed that the assignment order goes from RIGHT to
>>>> LEFT (I verified this in Lua 5.1, 5.2, 5.3, LuaJIT), or is it
>>>> "undefined behavior"?
>>> It is not undefined behavior at all.
>>> <snip>
>>> It is like in C, which does not specify the order of evaluation of
>>> expressions in argument lists in function calls.
>> You actually prove my point here.
> ...
>> You give two reasons.
>>
>> First, you say "it's implementation detail". That's no reason to not
>> state that it's "unspecified behavior".
>>
>> Second, you say "this allows us to change the implementation". Again:
>> that's no reason to not state that it's "unspecified behavior".
> ...
>> And that's wrong too.
> I am not easily shocked, but this response by an OP to a reply by
> a member of the Lua team is some of the worst trolling I have ever
> seen on any mailing list.

That response isn't humble, but it's correct. That's not what's called
'trolling'.

Reply | Threaded
Open this post in threaded view
|

Re: Documentation for multiple assignment fails to mention order

Soni "They/Them" L.


On 25/07/16 02:15 PM, Sergey Rozhenko wrote:

> On Пн 25.07.16 23:45, Dirk Laurie wrote:
>> 2016-07-25 18:28 GMT+02:00 Niccolo Medici <[hidden email]>:
>>> On 7/25/16, Luiz Henrique de Figueiredo <[hidden email]> wrote:
>>>>> The documentation for multiple assignment (section "3.3.3 –
>>>>> Assignment" in the manual) doesn't mention the fact the assignment is
>>>>> *not* carried out in order.
>>>>> <snip>
>>>>> BTW, is it guaranteed that the assignment order goes from RIGHT to
>>>>> LEFT (I verified this in Lua 5.1, 5.2, 5.3, LuaJIT), or is it
>>>>> "undefined behavior"?
>>>> It is not undefined behavior at all.
>>>> <snip>
>>>> It is like in C, which does not specify the order of evaluation of
>>>> expressions in argument lists in function calls.
>>> You actually prove my point here.
>> ...
>>> You give two reasons.
>>>
>>> First, you say "it's implementation detail". That's no reason to not
>>> state that it's "unspecified behavior".
>>>
>>> Second, you say "this allows us to change the implementation". Again:
>>> that's no reason to not state that it's "unspecified behavior".
>> ...
>>> And that's wrong too.
>> I am not easily shocked, but this response by an OP to a reply by
>> a member of the Lua team is some of the worst trolling I have ever
>> seen on any mailing list.
>
> That response isn't humble, but it's correct. That's not what's called
> 'trolling'.
>

You're right. However, the Lua manual is supposed to be terse, not a
200-page document.

Altho, anyone knows if this is well-defined?

local n = 0
local function nn()
   n = n + 1
   return n
end
local t = {}
t[nn()], t[nn()] = nn(), nn()

I'd expect it to work like

local temp1 = nn()
local temp2 = nn()
local temp3 = nn()
local temp4 = nn()
t[temp1], t[temp2] = temp3, temp4

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Documentation for multiple assignment fails to mention order

Roberto Ierusalimschy
In reply to this post by Niccolo Medici
> > > <snip>
> > > BTW, is it guaranteed that the assignment order goes from RIGHT to
> > > LEFT (I verified this in Lua 5.1, 5.2, 5.3, LuaJIT), or is it
> > > "undefined behavior"?
> >
> > It is not undefined behavior at all.
> > <snip>
> > It is like in C, which does not specify the order of evaluation of
> > expressions in argument lists in function calls.
>
> You actually prove my point here. The C standard *does* say that the
> order is "unspecified". [...]

Check your words. "unspecified behavior" (what the C standard says) is
different from "undefined behavior" (what you asked about). Lhf is
correct in saying that the behavior is not undefined, even though it is
unspecified.

About the manual itself: there are infinite things that Lua does not do
but the manual fails to mention. So, if the manual does not define in
what order __newindex metamethods in multiple assignments are called,
it is safe to assume that the order is unspecified, even if the manual
does not say that.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Documentation for multiple assignment fails to mention order

Coda Highland
On Mon, Jul 25, 2016 at 10:24 AM, Roberto Ierusalimschy
<[hidden email]> wrote:

> Check your words. "unspecified behavior" (what the C standard says) is
> different from "undefined behavior" (what you asked about). Lhf is
> correct in saying that the behavior is not undefined, even though it is
> unspecified.
>
> About the manual itself: there are infinite things that Lua does not do
> but the manual fails to mention. So, if the manual does not define in
> what order __newindex metamethods in multiple assignments are called,
> it is safe to assume that the order is unspecified, even if the manual
> does not say that.

Respectfully, I disagree with this argument. While it is true that
unspecified behavior is not the same as undefined behavior, undefined
behavior is tautologically defined as "behavior that is not defined".
The documentation for the language is the source of all definitions.
Any behavior that is not documented is therefore, by definition,
undefined behavior.

It can be concluded syllogistically that the execution order of
multiple assignments in Lua is undefined.

All undefined behaviors are unspecified, because in the case of Lua
the core language documentation is also the language specification.
The distinction is that when something is defined to be unspecified,
the scope of permissible behaviors is in the process implicitly
defined. (In this example, defining the order of assignments as being
unspecified would mean that any ordering would be permissible, but
that terminating the process -- not being an ordering of the
assignments -- would not be expected.)

That said, I don't disagree with your conclusion: The manual doesn't
say anything about it, so the order is undefined, and that's a
completely acceptable state of being.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Documentation for multiple assignment fails to mention order

Hisham

On 25 July 2016 at 15:07, Coda Highland <[hidden email]> wrote:
> On Mon, Jul 25, 2016 at 10:24 AM, Roberto Ierusalimschy
> <[hidden email]> wrote:
>> Check your words. "unspecified behavior" (what the C standard says) is
>> different from "undefined behavior" (what you asked about). Lhf is
>> correct in saying that the behavior is not undefined, even though it is
>> unspecified.
>>
>> About the manual itself: there are infinite things that Lua does not do
>> but the manual fails to mention. So, if the manual does not define in
>> what order __newindex metamethods in multiple assignments are called,
>> it is safe to assume that the order is unspecified, even if the manual
>> does not say that.
>
> Respectfully, I disagree with this argument. While it is true that
> unspecified behavior is not the same as undefined behavior, undefined
> behavior is tautologically defined as "behavior that is not defined".
> The documentation for the language is the source of all definitions.
> Any behavior that is not documented is therefore, by definition,
> undefined behavior.
>
> It can be concluded syllogistically that the execution order of
> multiple assignments in Lua is undefined.
>
> All undefined behaviors are unspecified, because in the case of Lua
> the core language documentation is also the language specification.
> The distinction is that when something is defined to be unspecified,
> the scope of permissible behaviors is in the process implicitly
> defined. (In this example, defining the order of assignments as being
> unspecified would mean that any ordering would be permissible, but
> that terminating the process -- not being an ordering of the
> assignments -- would not be expected.)
>
> That said, I don't disagree with your conclusion: The manual doesn't
> say anything about it, so the order is undefined, and that's a
> completely acceptable state of being.

I might be wrong here, but I suppose some of the confusion comes from the specific jargon for "undefined" vs. "unspecified" in the C standard, where "undefined behavior" means "if you do this anything can happen in the program including blowing up your computer", while "unspecified" is used in contexts such as "saying that A and B happen in an unspecified order means that A and B will happen, but you can't know in advance what the order is when writing a portable program".

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: Documentation for multiple assignment fails to mention order

Niccolo Medici
In reply to this post by Roberto Ierusalimschy
On 7/25/16, Roberto Ierusalimschy <[hidden email]> wrote:

>> > > <snip>
>> > > BTW, is it guaranteed that the assignment order goes from RIGHT to
>> > > LEFT (I verified this in Lua 5.1, 5.2, 5.3, LuaJIT), or is it
>> > > "undefined behavior"?
>> >
>> > It is not undefined behavior at all.
>> > <snip>
>> > It is like in C, which does not specify the order of evaluation of
>> > expressions in argument lists in function calls.
>>
>> You actually prove my point here. The C standard *does* say that the
>> order is "unspecified". [...]
>
> Check your words. "unspecified behavior" (what the C standard says) is
> different from "undefined behavior" (what you asked about). Lhf is
> correct in saying that the behavior is not undefined, even though it is
> unspecified.
>
> About the manual itself: there are infinite things that Lua does not do
> but the manual fails to mention. So, if the manual does not define in
> what order __newindex metamethods in multiple assignments are called,
> it is safe to assume that the order is unspecified, even if the manual
> does not say that.
>
> -- Roberto

Thank you for your reply.

I'll be going now to study the difference between "not undefined" to
"undefined" to "unspecified". I accept your judgment fully, so the
story is closed.

I did notice LHF's use of the phrase "not undefined" instead of
"unspecified", but I had to keep my post short so I removed that
section in my reply (which is fortunate because otherwise Dirk would
have had a stroke, not just a shock. I hope you didn't find me to be a
troll, or "not humble" as someone else said. I apologize if it perhaps
seemed this way. If it indeed seemed so, please let me know; I promise
not to reply - I'll just take it in mind seriously and try to learn
something from it).

Reply | Threaded
Open this post in threaded view
|

Re: Documentation for multiple assignment fails to mention order

Nagaev Boris
On Tue, Jul 26, 2016 at 8:17 PM, Niccolo Medici <[hidden email]> wrote:

> On 7/25/16, Roberto Ierusalimschy <[hidden email]> wrote:
>>> > > <snip>
>>> > > BTW, is it guaranteed that the assignment order goes from RIGHT to
>>> > > LEFT (I verified this in Lua 5.1, 5.2, 5.3, LuaJIT), or is it
>>> > > "undefined behavior"?
>>> >
>>> > It is not undefined behavior at all.
>>> > <snip>
>>> > It is like in C, which does not specify the order of evaluation of
>>> > expressions in argument lists in function calls.
>>>
>>> You actually prove my point here. The C standard *does* say that the
>>> order is "unspecified". [...]
>>
>> Check your words. "unspecified behavior" (what the C standard says) is
>> different from "undefined behavior" (what you asked about). Lhf is
>> correct in saying that the behavior is not undefined, even though it is
>> unspecified.
>>
>> About the manual itself: there are infinite things that Lua does not do
>> but the manual fails to mention. So, if the manual does not define in
>> what order __newindex metamethods in multiple assignments are called,
>> it is safe to assume that the order is unspecified, even if the manual
>> does not say that.
>>
>> -- Roberto
>
> Thank you for your reply.
>
> I'll be going now to study the difference between "not undefined" to
> "undefined" to "unspecified". I accept your judgment fully, so the
> story is closed.
>
> I did notice LHF's use of the phrase "not undefined" instead of
> "unspecified", but I had to keep my post short so I removed that
> section in my reply (which is fortunate because otherwise Dirk would
> have had a stroke, not just a shock. I hope you didn't find me to be a
> troll, or "not humble" as someone else said. I apologize if it perhaps
> seemed this way. If it indeed seemed so, please let me know; I promise
> not to reply - I'll just take it in mind seriously and try to learn
> something from it).
>

http://c-faq.com/ansi/undef.html explains the difference between
implementation-defined, unspecified, and undefined behavior.


--


Best regards,
Boris Nagaev

Reply | Threaded
Open this post in threaded view
|

Re: Documentation for multiple assignment fails to mention order

Dirk Laurie-2
In reply to this post by Niccolo Medici
2016-07-26 19:17 GMT+02:00 Niccolo Medici <[hidden email]>:

> I did notice LHF's use of the phrase "not undefined" instead of
> "unspecified", but I had to keep my post short so I removed that
> section in my reply (which is fortunate because otherwise Dirk would
> have had a stroke, not just a shock. I hope you didn't find me to be a
> troll, or "not humble" as someone else said. I apologize if it perhaps
> seemed this way. If it indeed seemed so, please let me know; I promise
> not to reply - I'll just take it in mind seriously and try to learn
> something from it).

If you are the same Niccolo Medici that used to be active on
NationStates, everything is already forgiven. That guy was
the one voice of sanity among some serious weirdos.

But you are forgiven anyway. My definition of 'troll' is 'an OP
who contributes 40% of the posts on his own thread', which
I admit I should not start applying when the thread has only
three messages in it. Sorry about that.