Re: Benefit of not defining the order of execution

On 14 Feb, 04:51, Tim Rentsch <t...@xxxxxxxxxxxxxxxxxxx> wrote:
Kaz Kylheku <kkylh...@xxxxxxxxx> writes:
On 2009-02-11, somenath <somenath...@xxxxxxxxx> wrote:

<snip>

[Kaz is arguing against C's undefined order of evaluation]

I'm not quite convinced, but I'm getting there


Even if it can be shown than unspecified order of evaluation provides an
undeniable performance benefit, there is no reason why that order has to be
unspecified in every part of the program, in every expression in every
function in every source file.

Apparently several people are of the opinion that having language
semantics be more deterministic is better than being not as
deterministic, because...  well, just because.

I think Kaz's argument was a little more robust than that

 To that I say, just 'tisn't so.

Even if a clever optimizing compiler could recover (relative to C as
it is now) all the possible parallelism of a C-like language with a
defined left-to-right order of evaluation (and it can't, but never
mind that now), it still isn't automatically better to impose a
left-to-right evaluation order, or any fixed evaluation order.  In
fact, doing that to C expressions would make C a worse language,
not a better one.  Here's why.

If I see a piece of C code like, for example,

   a = f( g(x), h(y) );

then I don't have to look at the definitions for g() and h() to know
they don't interact (by which I mean, interact in any nontrivial
way).  The reason?  If they did interact, the code would have been
written differently, to force a particular order of evaluation.

rubbish. As others have pointed out you assume error-free programmers


Of course, technically I don't know that g() and h() don't interact;

quite

I know only that the person who wrote the code didn't think it was
important to force a particular order of evaluation.

or just didn't think. Most programmers assume left to right
evaluation and would be quite surprised if they were told they
were wrong.


 But knowing
the intent (or in this case, the lack of intent) of the code's
author is just as valuable here, or perhaps more valuable.

I don't see that

 I can
always go look at the definitions for g() and h() to see if they
interact, but I can't go back and look at what the code's author
was thinking.

Now consider the case where the language specifies a left-to-right
evaluation order.  Let's look again at the example line.  Now I have
to wonder if g() and h() interact;

this is crazy! You claim that making the code more predictable
makes the code harder to analyse!


 to find out I have to go read
their definitions.  If they don't interact, I can breathe a big sigh
of relief and go back to reading the function where they were
called.  But suppose they do interact;  in that case I have to
wonder if the interaction was known and deliberate, or whether it
might have been unintentional.  Short of going back and asking the
original author, there really isn't any way of knowing.  Discovering
what the program does and what the program was intended to do has
become a lot more work.

I cannot agree

<snip>


--
Nick Keighley
.

Relevant Pages

  • Re: Benefit of not defining the order of execution
    ... left-to-right evaluation order, ... they don't interact (by which I mean, ... There is one other way in which undefined order of evaluation ... Unspecified OoE often is the cause of undefined behavior. ...
    (comp.lang.c)
  • Re: Benefit of not defining the order of execution
    ... Even if a clever optimizing compiler could recover (relative to C as ... left-to-right evaluation order, ... they don't interact (by which I mean, ... There is one other way in which undefined order of evaluation ...
    (comp.lang.c)
  • Re: Benefit of not defining the order of execution
    ... they don't interact (by which I mean, ... to force a particular order of evaluation. ... Which underscores the point that as soon as evaluation order is ... distant future I can see an optimizer deciding that fand gcan be evaluated ...
    (comp.lang.c)
  • Re: unusual OR syntax
    ... The same can be achieved without using short circuit evaluation, ... It's a feature of the language. ... features of the language is a crime in itself. ... it is there for a reason: In case the second expression doesn't ...
    (comp.lang.php)
  • Re: Benefit of not defining the order of execution
    ... they don't interact (by which I mean, ... to force a particular order of evaluation. ... FWIW in this language strcat was the only ... distant future I can see an optimizer deciding that fand gcan be evaluated ...
    (comp.lang.c)