Re: undefined compound chaining behavior

[John W. Eaton]

Please stop. Your argument that Octave's behavior for expressions like

  x += x += y

is undefined because the same expression has undefined behavior in C++ 
is not correct.

As others have told you repeatedly, Octave does not work by translating 
this expression into a compound += expression in C++.  So the C++ 
compiler never sees a compound += expression.  Instead, Octave generates 
a function call that performs a single OP= operation.  Even if that 
operation ultimately uses the C++ += operator (which it usually does 
not), it only performs one += operation at a time. There is no 
opportunity for the C++ compiler to ever see a chained += operation.

The behavior for this expression in Octave IS NOT UNDEFINED.  You are 
simply wrong about that assertion.  Continuing to argue about it just 
shows your ignorance of the way in which Octave's interpreter is 
implemented.  So please stop arguing about it.

However, you have brought to my attention the fact that the behavior of 
Octave's interpreter when evaluating a compound expression like

  x += x += y

conflicts with our promise that expressions like

  x OP= y

are syntactically equivalent to

  x = x OP y

This conflict is not intentional.  It seems to me that we have three 
options:

  1. leave the behavior as it is now, but document it

  2. disallow chained OP= expressions

  3. change Octave's behavior so that our promise about the way OP= 
expressions are handled is always true

If we allow the OP= expressions to be chained and we wish to keep our 
promise about they way OP= expressions are evaluated, then I believe an 
expression like

  x += x += y

should be evaluated as

  x = x + (x += y)

which would be the same as

  x = x + (x = (x + y))

Currently, the expression is evaluated as if it is

  x = (x = (x + y)) + x

In other words, the RHS (the second += operation) is evaluated first, 
then the new value of X is added to that result.

If we do decide to continue to allow OP= expressions to be chained and 
we change the behavior, then we'll need to be careful in making such a 
change because there may be code that relies on the old behavior.  At 
the very least, I think we should warn about the change.

jwe