Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68273
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.175 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAL+t6cEVGjGin9B-zsJ8CpRo5hFgcYuZLP79tVekMWU3gkCFTg@mail.gmail.com>
References: <CAGa2bXbWCKBx1=x0Jmo0=L0ixkSx28J4vf71i0g=PHdAyStc4Q@mail.gmail.com>
 <51EA3E36.1090402@sugarcrm.com> <CAL+t6cEHoZubOFMszMDaB8deByKGbA7HCx+3PVuLTFKZCE0TMA@mail.gmail.com>
 <51EAF928.3060604@sugarcrm.com> <CAL+t6cEVGjGin9B-zsJ8CpRo5hFgcYuZLP79tVekMWU3gkCFTg@mail.gmail.com>
Date: Sun, 21 Jul 2013 11:52:00 +0900
Message-ID: <CAGa2bXaLemVZKq+u+R_B-uA-TY5s3ALypS_aiH-LH2wE=a-wSw@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c37b0a50ac0c04e1fca72f
Subject: Re: [PHP-DEV] Operator precedence is undefined?
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c37b0a50ac0c04e1fca72f
Content-Type: text/plain; charset=UTF-8

Hi all,

2013/7/21 Sherif Ramadan <theanomaly.is@gmail.com>

> The problem is I'm not sure where this type of information should be
> documented. It makes sense to put this on the increment/decrement operators
> page, but doesn't seem appropriate the operator precedence page. So to make
> sure we're all in agreement I'm suggesting the following language to be
> added as a note on the increment/decrement operators page at
> www.php.net/language.operators.increment with supplement examples
> provided above to help users get a better understanding of what we mean
> when we say undefined behavior and add an additional warning box not to
> rely on this type of behavior.
>

Since the issue int "++$a + $a++" is not a precedence issue, but a
evaluation orders and side effects. Describing it without complete
explanation in precedence section makes users confuse. (I'm the one also)

I partially agree that documenting the issue in
www.php.net/language.operators.increment . It would better to be described
fully in a section since it is not a increment/decrement only issue.


> "As noted from the examples above the use of multiple increment/decrement
> operators in the same expression is considered undefined behavior because
> the order of evaluation cannot be guaranteed. Using such evaluations may
> lead to unexpected results."
>
> "Warning:
> Relying on this behavior is discouraged as it may be subject to change and
> without notice. Results are not typical and are implementation-specific."
>
>
These will fit into www.php.net/language.operators.increment.



If PHP is going to inherit C/C++ feature for better compiler implementation
and parallelism, we should document fully.
(Note: Java/C# seem always evaluate left to right and side effect is
immediately visible. Therefore, Java/C# don't have undefined behaviors like
C/C++. It's possible to behave like Java/C#, but PHP is going to follow
C/C++ way I suppose.)

http://en.cppreference.com/w/cpp/language/eval_order
 1) Between the previous and next sequence point a scalar object shall have
its stored value modified at most once by the evaluation of an expression.
i = ++i + i++; // undefined behavior
i = i++ + 1; // undefined behavior
i = ++i + 1; // undefined behavior (well-defined in C++11)
++ ++i; // undefined behavior (well-defined in C++11)
f(++i, ++i); // undefined behavior
f(i = -1, i = -1); // undefined behavior
2) Between the previous and next sequence point , the prior value of a
scalar object that is modified by the evaluation of the expression, shall
be accessed only to determine the value to be stored.
cout << i << i++; // undefined behavior
a[i] = i++; // undefined bevahior

In PHP, it would be

$i = ++$i + $i++;
$i = $i++ + 1;
$i = ++$i + 1;
++ ++$i;
f(++$i, ++$i); // This is good for parallelism. e.g. parameter evaluation
can be done in parallel.  f(complex_func(), extremely_complex_func());
f($i = -1, $i = -1); // Same as above
echo $i, $i++; // Same as above
$a[$i] = $i++;

The best benefit of undefined evaluation order is parallelism (i.e. out of
order execution) even if PHP doesn't have it now. C/C++ doesn't execute
function parameters in parallel automatically, but PHP doesn't have to
follow this.

It would be good to have dedicated section for this. Discussion would be
needed if PHP is going to support out of order execution for func(f1(),
f2(), f3()) or like, which one make undefined, adding more undefined, etc.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c37b0a50ac0c04e1fca72f--