Re: Benefit of not defining the order of execution

On Tue, 17 Feb 2009 08:35:29 -0800, Keith Thompson
<kst-u@xxxxxxx> wrote:

nick_keighley_nospam@xxxxxxxxxxx writes:
On 14 Feb, 04:51, Tim Rentsch <t...@xxxxxxxxxxxxxxxxxxx> wrote:
[...]
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.

"Most programmers"? If that statement is based on actual data, that's
interesting (and disappointing); if not, it would be good to see some
actual data.

I doubt that there is any such data. It sounds plausible,
though, because people read ordinary text left to right.
Presumably they also read code the same way, i.e., by default
they interpret it left to right. This could create the
unconscious assumption that the evaluation is left to right, even
if they know better.

But it's only plausible.


[...]

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!

(The context was a = f( g(x), h(y) );.)

If you assume a sufficiently competent programmer, you can assume
that g(x) and h(y) don't interact, because if they did then the
programmer wouldn't have written that statement. On the other hand,
"sufficiently competent" may approach "never makes mistakes".
On the other other hand, g(x) and h(y) *shouldn't* interact; if they
do, nailing down the order of evaluation makes the code well-defined,
but still poor style.

All of this depends upon the kind of analysis. If you are trying
to understand the operation of a piece of code, the default
assumption is that the author got it right. If you are trying to
debug it, the default assumption is that the author got it wrong.


Richard Harter, cri@xxxxxxxx
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.
.

Relevant Pages

  • Re: subroutine stack and C machine model
    ... If you are referring to left-to-right evaluation, ... determined by the programmers of compilers...for the same reason that ... obsolete language APL enforced right to left evaluation. ... each compiler's choice was a defacto standard. ...
    (comp.lang.c)
  • Re: Benefit of not defining the order of execution
    ... I'd like to ask people who favor defining order of evaluation ... Unspecified OoE isn't as simple as settling on one particular ... that gand hshould not interact, ... The argument presented is that "clever" programmers will do bad ...
    (comp.lang.c)
  • Re: Benefit of not defining the order of execution
    ... important to force a particular order of evaluation. ... Most programmers assume left to right ... they have experimented with their favorite compiler to find out what that order is. ... What your example shows is that there is actually no need to specify which side of the road all cars must drive on, since both cases can be accommodated; likewise, there is no need to specify in what order C compilers evaluate expressions, since all orders can be accommodated. ...
    (comp.lang.c)
  • Re: subroutine stack and C machine model
    ... requirements as to order of evaluation except when there's a sequence ... You have claimed that the standard "requires nondeterminism". ... because most C programmers stay with one ... You keep doing all this ranting, but you never actually present evidence ...
    (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. ... As others have pointed out you assume error-free programmers ... imposing left-to-right evaluation order would be at least as bad ...
    (comp.lang.c)