octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: undefined compound chaining behavior


From: Hossein Sajjadi
Subject: Re: undefined compound chaining behavior
Date: Mon, 9 Jun 2014 19:57:09 +0330

I evaluated the expression on some languages:

languages that the expression will result 6 are:
Java , C# ,bash , julia , Ruby , javascript

languages that the expression will result 10 are:
C++ ,C , Objective-C , D , Octave, Perl , PHP , AWK , batch , Windows Powershell

with regard to C-C++ standard such an expression results in undefined behavior

I accept that "the result is always going to be 10 in Octave and there
is no concept of "undefined behaviour" in the Octave language"(Jordi
GutiƩrrez Hermoso as of probably core developer of the interpreter
said), but I can say that developers of  languages such as PHP, perl,
octave ,.. did not take into account undefined behavior in c/c++ and
based their interpreter/compiler on wrong assumptions ,in the other
words result of c++ expression is wrong and octave developers simulate
the wrong behavior.
Jordi sayid "There is no Matlab or Octave standard" so anything is
possible in Octave.


On 6/9/14, Daniel J Sebald <address@hidden> wrote:
> On 06/06/2014 01:12 PM, Rik wrote:
>> On 06/06/2014 08:06 AM, address@hidden wrote:
>>> Message: 5
>>> Date: Fri, 6 Jun 2014 17:20:08 +0330
>>> From: Hossein Sajjadi<address@hidden>
>>> To: address@hidden
>>> Subject: chaining compound assignment results in undefined behavior
>>> Message-ID:
>>>     <address@hidden>
>>> Content-Type: text/plain; charset=UTF-8
>>>
>>> Hi
>>>
>>> There is a problem with chaining compound assignment.
>>> For example the expression a=1;a+=a+=4 will result 10.
>>> I think such a behavior is borrowed from C language but this behavior
>>> is known as "undefined behavior".
>>>   This issue have been resolven in Java.
>>>   Java language guarantees that the operands of operators appear
>>> to be evaluated in a specific evaluation order , namely, from left to
>>> right. ?15.7
>>> Other specifications about evaluation of expressions are in
>>> "The Java? Language Specification"
>>>
>>>   also this approach is followed by c# language
>>>   so result of above expression in Java is 6
>>
>> I don't think we need to do anything here.  First, code should
>> self-documenting and easy to understand.  When I first looked at the
>> statement I couldn't figure out what the intent was, and so I'm not
>> surprised that the compiler also has a hard time deciding what to do.
>> So,
>> I would suggest that rather than introduce complexities in to the parser,
>> the programmer should simply write what they mean.
>>
>> If the programmer wants 6 as an answer, then code
>> a = 1; a += a; a+= 4
>>
>> If the programmer wants 10 as an answer, then code
>> a = 1; a +=4; a += a
>>
>> I tried the example in C++ and the result with the gcc compiler is 10 so
>> I'm perfectly happy to define the behavior that multiple in-place
>> operators
>> are evaluated in a specific evaluation order which happens to be "right
>> to
>> left".
>
> Also, I'm not so sure the right-to-left evaluation makes sense because
> this is both an operation and assignment in one.  Explicitly applying
> associativity using parentheses, think about:
>
> octave-cli:7> a=1;a+=(a+=4)
> a =  10
>
> which makes sense, I guess.  The parentheses are evaluated with an
> inherent assignment and serves as an input to the proceeding add/assign.
>   But the following makes no sense:
>
> octave-cli:8> a=1;(a+=a)+=4
> parse error:
>
>    invalid left hand side of assignment
>
>>>> a=1;(a+=a)+=4
>
> and the parser gives up, appropriately.  The first parentheses is an
> evaluation (i.e., quantity) and the add/assign can only apply to a
> variable, not a quantity.
>
> Dan
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]