Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68254
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.176 as permitted sender)
MIME-Version: 1.0
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: Sat, 20 Jul 2013 06:27:14 +0100
Message-ID: <CAPwsocGXtPqA-ELDfG0S63xC2A0CVOv6HPgxzdzjamQvKOK3kw@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013a2a622bb78b04e1eab2ea
Subject: Re: [PHP-DEV] Operator precedence is undefined?
From: leight@gmail.com (Leigh)

--089e013a2a622bb78b04e1eab2ea
Content-Type: text/plain; charset=ISO-8859-1

I'm disappointed $a+++++$a doesn't work as expected :(


On 20 July 2013 06:08, 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
> >>
> >
> >
>

--089e013a2a622bb78b04e1eab2ea--