NM> DZ > &-predictable order of evaluation. It is the one that
NM> DZ > is written into the source. It is THIS one that is
NM> DZ > reliably & efficiently computable, albeit with a big
NM> DZ > hit in parallelism.
NM> DZ >
NM> DZ > Most languages have either a specified or implied
NM> DZ > order of evaluation. That's the one that's predictable.
NM>
NM> Do they? Of the dozens that I am familiar with, only Java explicitly
NM> specifies the order of evaluation. Most of them specify the operator
NM> precedence, but that is a syntactic concept and not a semantic one.
NM>
NM> Some people have attempted to rewrite history by claiming that the
NM> semantic order is required to follow the syntax, but that has NOT
NM> achieved consensus (for good reasons) except in a few languages like
NM> Java.
NM>
NM> DZ > I am aware that Fortran specifies that the order of
NM> DZ > evaluation is effectively NOT specified. I am also
NM> DZ > aware that, while it IS specified in C, it is also
NM> DZ > routinely ignored.
NM>
NM> That's misleading. It is EXPLICITLY unspecified for Fortran,
The truth is in between. The Fortran standard is more complicated than either specified or unspecified.
Within an _expression_, the standard lets the programmer use parentheses to explicitly partially specify the evaluation order or leave it unspecified. In other situations it is partly unspecified.
Examples:
a+b+c has an unspecified order and can be evaluated as (a+b)+c or as a+(b+c) or as (a+c)+b. It's up to the compiler to choose.
(a+b)+c has a specified order and must be evaluated as (a+b)+c with the a+b done first.
a+(b+c) has a specified order and must be evaluated as a+(b+c) with the b+c done first.
In these last two, the compiler has no choice (unless the user specifies some option like IBM's -qnostrict giving it a choice).
a+b+c+d has an unspecified order.
a+(b+c)+d has a partially specified order, and can be evaluated as (a+(b+c))+d or as a+((b+c)+d) or as (a+d)+(b+c) or as (b+c)+(a+d). (The last two may differ if an exception leads to a trap.)
f(x)+g(x) has an unspecified order between the f and g function calls.
f(g(x),h(x)) has an unspecified order between the g and h function calls (and if either changes x or a global variable read by the other, or does I/O, it can affect the result).
In these last two, the result is undefined.
but splitting the last one into three statements
t1 = g(x)
t2 = h(x)
f(t1,t2) has a specified order.
Some programmers do use this to control evaluation order, and all compilers must support it. Some also take advantage of unspecified ordering to improve performance.
- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development
"N.M. Maclaren" ---08/04/2011 01:18:07 PM---On Aug 4 2011, Dan Zuras Intervals wrote: >