Re: Benefit of not defining the order of execution

On Wed, 18 Feb 2009 06:36:54 +0000, Flash Gordon
<smap@xxxxxxxxxxxxxxxxx> wrote:

Richard Harter wrote:
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.

There are people who strongly believe that the arguments are evaluated
right to left and pushed on to the stack as this is done. Thus when the
function is called the left most argument is a fixed offset from the
stack pointer making life simple for the compiler.

IIANM you can do it simply either way - it's a matter of how you
set up your stack usage conventions. Be that as it may, I
suspect that most programmers never give a thought about the
order of evaluation until they get their nose rubbed in it.


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. (Think regression tests
on log files.)




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.

When I'm analysing code for any reason my default assumption is that
there will be a bug somewhere, after all no one is perfect!

That has been my experience as well, particularly me.


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)