Re: Benefit of not defining the order of execution

Nate Eldredge <nate@xxxxxxxxxx> writes:
cri@xxxxxxxx (Richard Harter) writes:
On Wed, 18 Feb 2009 06:36:54 +0000, Flash Gordon
<smap@xxxxxxxxxxxxxxxxx> wrote:
Sine different people assume different orders (and some know the order
is unspecified as far as the language is concerned) forcing a specific
order on compilers will certainly still leave people getting it wrong
*and* will make some implementations less efficient. Seems like a
loose-loose option to me.

I disagree; it's not a lose-lose option. However the issue of
peoples assumptions being satisfied or not satisfied is not
particularly important. What is important, IMNSHO, is that
outputs of working conforming programs can vary depending on
evaluation order choices by compilers.

But that's just the point: programs that depend on the evaluation order
are NOT conforming.

They're not portable, but there's nothing non-conforming about
depending on evaluation order as long as you avoid undefined behavior.
If a program's output depends on unspecified evaluation order, then it
can't be *strictly* conforming, but it can certainly be conforming.
Actually, the standard's definition of "conforming program" is very
weak, but as long as any difference in behavior isn't significant to
the program's functionality, such a program can even be portable.

(Think regression tests
on log files.)

Huh?

Consider a program containing something like this:

double result = this() * that() + the_other();

Assuming that the three functions don't interact in any nasty ways
(depending on the same global variables, for example), the order of
evaluation shouldn't matter; result will get the same value for any of
the 6 possible orders. But suppose the functions contain trace
statements that (perhaps optionally) log information to a file. Then
the contents of the log can vary depending on the evaluation order,
and a testing scheme that looks for possible regressions by detecting
changes in the contents of the log will have problems.

--
Keith Thompson (The_Other_Keith) kst@xxxxxxx <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • Re: Benefit of not defining the order of execution
    ... outputs of working conforming programs can vary depending on ... evaluation order choices by compilers. ... programs that depend on the evaluation order ... Most Lisp code qualifies, ...
    (comp.lang.c)
  • Re: behavior-preserving optimization in C, was compiler bugs
    ... programs for their compilers rely on the order, ... different implementations do it differently. ... evaluation order, run just fine if the evaluation order is changed. ... But - I think you are wrong about what an optimizer is for. ...
    (comp.compilers)
  • Re: Benefit of not defining the order of execution
    ... is unspecified as far as the language is concerned) forcing a specific ... loose-loose option to me. ... evaluation order choices by compilers. ... programs that depend on the evaluation order ...
    (comp.lang.c)
  • Re: Benefit of not defining the order of execution
    ... loose-loose option to me. ... outputs of working conforming programs can vary depending on ... evaluation order choices by compilers. ... programs that depend on the evaluation order ...
    (comp.lang.c)
  • Re: Announcing a new release of Lisp1 #2
    ... On Wed, 30 Jan 2008, Blake McBride wrote: ... I would further add that Scheme should define argument evaluation order. ... Compilers can be written to support a particular order just as well as ...
    (comp.lang.lisp)