Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68251
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.51 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAGa2bXbw-hmfCJaY97NhfaSMp_7=sah4oivqsrprUs1SjngHVA@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>
Date: Fri, 19 Jul 2013 21:44:46 -0700
Message-ID: <CAESVnVrRwMnnpH_1gCQ7RLM7wKZ7A2Pwu_ZUyYO=Kjhj7UQ4fA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Sherif Ramadan <theanomaly.is@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b339f17484ef504e1ea1a71
Subject: Re: [PHP-DEV] Operator precedence is undefined?
From: pollita@php.net (Sara Golemon)

--047d7b339f17484ef504e1ea1a71
Content-Type: text/plain; charset=ISO-8859-1

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 (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.

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.


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
>

--047d7b339f17484ef504e1ea1a71--