Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68253
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVrRwMnnpH_1gCQ7RLM7wKZ7A2Pwu_ZUyYO=Kjhj7UQ4fA@mail.gmail.com>
References: <CAGa2bXbWCKBx1=x0Jmo0=L0ixkSx28J4vf71i0g=PHdAyStc4Q@mail.gmail.com>
	<CAESVnVrpRmwG-hTwdNu1j60vLriG9PRfis7N8xJUKCEwjgEKaA@mail.gmail.com>
	<CAGa2bXb_763hvMu2e-D9fEXYO2fVgpNP=eByZZW9xH1COTZWeQ@mail.gmail.com>
	<CAL+t6cHzoCRmNcMTKu9Te9ZgC7DZMRUdy0_dExs4D=v_qGDyNA@mail.gmail.com>
	<CAGa2bXbKQyrCV8dabNRcJbfCQZV_iFvhFr4e0Nfu0kKRdvM68A@mail.gmail.com>
	<CAESVnVrXVbban6+zr_2Me7rKYp_n-j8Gx54vh2Mry1kwpk428Q@mail.gmail.com>
	<CAGa2bXbw-hmfCJaY97NhfaSMp_7=sah4oivqsrprUs1SjngHVA@mail.gmail.com>
	<CAESVnVrRwMnnpH_1gCQ7RLM7wKZ7A2Pwu_ZUyYO=Kjhj7UQ4fA@mail.gmail.com>
Date: Sat, 20 Jul 2013 01:08:30 -0400
Message-ID: <CAL+t6cG2PKp3xexFAJJNuY51SK+k1uTbgh0KqFdtxMcLACL+rQ@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11333dce30a4da04e1ea6f12
Subject: Re: [PHP-DEV] Operator precedence is undefined?
From: theanomaly.is@gmail.com (Sherif Ramadan)

--001a11333dce30a4da04e1ea6f12
Content-Type: text/plain; charset=ISO-8859-1

Sara,

On Sat, Jul 20, 2013 at 12:44 AM, Sara Golemon <pollita@php.net> wrote:

> What's undefined isn't the relationship between preinc/postinc and add.
>  What's undefined is the use of multiple preinc/postinc operators within a
> single expression
>

I'm sorry but I can not find any evidence of how that is undefined. The
operators are right-associative, with a defined level or precedence. Their
operands are well defined and their return value in the expression is
determined by the compiler, not the parser. In this sense the compiler
always executes those opcodes first and returns a temporary variable.


> (preincrements in particular).  Our parser grammer, as it currently
> stands, does have a predictable order, but that is a side-effect of
> implementation.  The language's definition of order of resolution of
> multiple preinc/postinc elements within a single ticked statement is that
> they are undefined.  And *that* is what made your *particular* change to
> the documentation incorrect.
>

The parser grammar in general is pretty muddled, I will agree with that.
However, the precedence order here is well defined within the expression. I
can not see any condition under which the compiler will introduce
unpredictable order of these opcodes or their results.


>
> If you'd like to define behavior for:  echo ++$a + 1;  then that's a
> different matter.  Defining the behavior of ++$a + $a++, however is
> inviting misunderstanding*.
>
> What was inappropriate, was asking for comment, receiving comment which
> cited an issue, then committing without discussing that issue first.
>
> -Sara
>
> * Even if, technically, either order of evaluation will result in the same
> answer for this contrived expression.  ++$a * $a++ is a more obviously
> ambiguous answer for a language which explicitly does not define an order
> of resolution.
>

By that logic we should indicate that -$a * $a is also undefined behavior?
I know the parser grammar is not well-defined and I'm taking this fact into
consideration, but here we are talking about operators which will compile
down into very much well-defined opcodes and have a predictable order of
resolution. It's quite possible that someone could introduce a change later
on that will cause a different result, but the likelihood of that becoming
a reality is slim-to-none.

I'm not a fan of getting into cat and mouse games over these types of
discussions, however. I posed my opinion on this matter and I refuse to
overwrite someone's commit because I feel my opinion is the only one that
counts. I am certainly not above being wrong. I just want to be sensible.


>
>
> On Fri, Jul 19, 2013 at 9:28 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>> Hi Sara,
>>
>> 2013/7/20 Sara Golemon <pollita@php.net>
>>
>>> On Fri, Jul 19, 2013 at 7:16 PM, Yasuo Ohgaki <yohgaki@ohgaki.net>wrote:
>>>
>>>>
>>>>
>>>> If there aren't comments, I'll rewrite the example.
>>>>
>>>>
>>>> There were comments.  I explicitly told you that that the behavior is
>>> defined as undefined.  You CHOSE to ignore that comment.  You CHOSE to
>>> break the documentation.
>>>
>>
>> If there is defined precedence, arithmetic operation should follow it.
>> If there is exception, it should be documented.
>>
>> I don't understand why/how the arithmetic operation can be
>> ambiguous with defined precedence. (++ and -- are higher than +)
>>
>> $a = 1;
>> echo ++$a + $a++;
>>
>> should always print 4 with current PHP precedence definition.
>>  If it does not, it's a bug in language.
>>
>> // mixing ++ and + produces undefined behavior
>> $a = 1;
>> echo ++$a + $a++; // may print 4 or 5
>>
>> I don't see any reason it became undefined.
>> If this kind of simple precedence is broken, how programmers write
>> code and/or trust the language?
>>
>> http://3v4l.org/mR4da/vld#tabs
>>
>> This site seems support PHP 4.3.0 to PHP 5.5.0 and opcode looks
>> fine. Am I missing something?
>>
>> If you would like to suggest use of (), it should be done differently.
>> IMHO.
>> The comment only ruins PHP's reputation as language.
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohgaki@ohgaki.net
>>
>
>

--001a11333dce30a4da04e1ea6f12--