[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: undefined compound chaining behavior
From: |
John W. Eaton |
Subject: |
Re: undefined compound chaining behavior |
Date: |
Fri, 13 Jun 2014 11:58:21 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 |
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
- Re: undefined compound chaining behavior, (continued)
- Re: undefined compound chaining behavior, Hossein Sajjadi, 2014/06/13
- Re: undefined compound chaining behavior, Richard Crozier, 2014/06/13
- Re: undefined compound chaining behavior, Hossein Sajjadi, 2014/06/13
- Re: undefined compound chaining behavior, Richard Crozier, 2014/06/13
- Re: undefined compound chaining behavior, Hossein Sajjadi, 2014/06/13
- Re: undefined compound chaining behavior, Ben Abbott, 2014/06/13
- Re: undefined compound chaining behavior, Hossein Sajjadi, 2014/06/13
- Re: undefined compound chaining behavior, Ben Abbott, 2014/06/13
- Re: undefined compound chaining behavior, Hossein Sajjadi, 2014/06/13
- Re: undefined compound chaining behavior, Benjamin Abbott, 2014/06/13
- Re: undefined compound chaining behavior,
John W. Eaton <=
- Re: undefined compound chaining behavior, Mike Miller, 2014/06/13
- Re: undefined compound chaining behavior, John W. Eaton, 2014/06/13
- Re: undefined compound chaining behavior, Michael D. Godfrey, 2014/06/13
- Re: undefined compound chaining behavior, Hossein Sajjadi, 2014/06/13
- Should "ans" include all side effects?, Daniel J Sebald, 2014/06/13
- Re: Should "ans" include all side effects?, Daniel J Sebald, 2014/06/13
- Re: Should "ans" include all side effects?, Daniel J Sebald, 2014/06/13
- Re: undefined compound chaining behavior, Stefan Seefeld, 2014/06/12
- Re: undefined compound chaining behavior, Hossein Sajjadi, 2014/06/13
- Re: undefined compound chaining behavior, Benjamin Abbott, 2014/06/10