Re: Documentation for multiple assignment fails to mention order

[Niccolo Medici <niccolomedici@...>]

On 7/25/16, Luiz Henrique de Figueiredo <lhf@tecgraf.puc-rio.br> 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