Re: Benefit of not defining the order of execution

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.

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.

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!
--
Flash Gordon
.

Relevant Pages

  • Re: unusual OR syntax
    ... should be considered essential knowledge for a programmer. ... Constructing logic using short-circuit evaluation tends to be a lot more compact, and I can easily see the advantages of that. ... Functions return a value that will be evaluated as a boolean when used like this. ... The right hand expressions is NOT evaluated when the left hand expression evaluated to true in case of OR. ...
    (comp.lang.php)
  • Re: unusual OR syntax
    ... should be considered essential knowledge for a programmer. ... It is for someone who understands programming and the language. ... I remember being quite suprised when I encountered this short-circuit evaluation (in Perl in my case). ...
    (comp.lang.php)
  • Re: Implicitly-concurrent-Scheme
    ... Just parallelizing argument evaluation is not sufficient - not to ...  The best execution model, IMO, is some kind of eager ... I've been working - slowly - on a proof of concept compiler. ... scalability or in practical use by the average programmer (who, ...
    (comp.lang.scheme)
  • Re: Verbose functional languages?
    ... Marshalling forces evaluation of the values marshalled. ... As programmer you typically know very ... Console output is not /only/ for debugging but expected program behaviour ...
    (comp.lang.functional)
  • Re: Benefit of not defining the order of execution
    ... important to force a particular order of evaluation. ... ``Specified in a way that surprises someone'' is unequivocally better ... That programmer would still find that although his expectation was incorrect, ... And note that the surprised programmer still had expectations of /an/ order, ...
    (comp.lang.c)