Should "ans" include all side effects?

[Daniel J Sebald]

On 06/13/2014 10:58 AM, John W. Eaton wrote:

> 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

This is just a dodgy subject, rooted in the inherent contradiction of 
the expression

a = a + 1

which really means "replaced by", or "becomes".  Here are a couple 
examples of expressions I'm not comfortable with.  (But I don't worry 
too much about them because I avoid them in a scripted language.)

octave-cli:127> a=1; x = a + sin(a++)
x =  1.8415
octave-cli:128> a=1; x = sin(a++) + a
x =  2.8415

The scripted language evaluates differently based upon commuted order 
because the a++ operator is evaluated at the point of occurrence.  If 
I'm not mistaken, C would handle the side effects after the whole 
instruction is evaluated.  I'm not comfortable with the 
non-commutativity of it, that's all.

And here's one that we really should give some thought too.  What do we 
consider the evaluated result to be, i.e., the command line following 
the expression?  Is "ans" the result "after the fact" or "during the 
evaluation"?  Consider this initially odd result:

octave-cli:129> a=1; a = a + 1
a =  2
octave-cli:130> a=1; a++
ans =  1
octave-cli:131> a
a =  2

Certainly, this is OK:

octave-cli:132> a=1; x = a++
x =  1

but I'm not certain about:

octave-cli:130> a=1; a++
ans =  1

Dan