Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68255
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.220.54 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAL+t6cG2PKp3xexFAJJNuY51SK+k1uTbgh0KqFdtxMcLACL+rQ@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>
	<CAL+t6cG2PKp3xexFAJJNuY51SK+k1uTbgh0KqFdtxMcLACL+rQ@mail.gmail.com>
Date: Fri, 19 Jul 2013 22:33:08 -0700
Message-ID: <CAESVnVqKGdH9wN__hc+VaOWViT4Uq8TrBywMeOKhvCdn4CD-sA@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bd6b50a49f2a804e1eac7dc
Subject: Re: [PHP-DEV] Operator precedence is undefined?
From: pollita@php.net (Sara Golemon)

--047d7bd6b50a49f2a804e1eac7dc
Content-Type: text/plain; charset=ISO-8859-1

Your example "-$a * $a" isn't at all the same because -$a doesn't produce
side-effects, only output.

I never said that the compiler might magically produce differing results
for the same input.  I said that the language's definition does not declare
a defined behavior for such expressions with combined side effects.

As to reverting commits.  When the initial commit was made in haste during
an active discussion, a revert is entirely appropriate and has nothing to
do with placing one's opinion over another's.  It has to do with placing
the process of consensus building over unilateral cowboy commits.

-Sara


On Fri, Jul 19, 2013 at 10:08 PM, Sherif Ramadan <theanomaly.is@gmail.com>wrote:

>
> 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
>>>
>>
>>
>

--047d7bd6b50a49f2a804e1eac7dc--