Re: undefined compound chaining behavior

[Mike Miller]

On Fri, Jun 13, 2014 at 11:58:21 -0400, John W. Eaton wrote:
> 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.

Yes please, this discussion has gone way past the point of being
productive or interesting. Any further discussion should focus on
whether to better document the current behavior as I suggested days
ago, or to change the order of evaluation, re:

> 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.

It seems to me that multiple people that have participated in this
thread find the current behavior quite intuitive and correct as it is.
I personally find it quite reasonable that operators that associate
right-to-left also evaluate their arguments right-to-left.

I would prefer option 1, add a note to the manual similar to what I
suggested earlier in this thread, something along the lines of

---
  An expression of the form

       EXPR1 OP= EXPR2

  is evaluated as

       EXPR1 = (EXPR1) OP (EXPR2)

  as long as EXPR2 is a simple expression with no side effects. If EXPR2
  also contains an assignment operator, then this expression is
  evaluated as

       temp = EXPR2
       EXPR1 = (EXPR1) OP temp

  where 'temp' is a placeholder temporary value storing the computed
  result of evaluating EXPR2.
---

> 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.

If we do decide it does need to be changed, yes a warning is warranted
that should help track down all such usages.

-- 
mike