Re: Depending on passing mechanism

[dewar@merv.cs.nyu.edu (Robert Dewar)]

<<        I have seen this particular claim challenged by several other
compiler writers and no evidence was advanced to support it. Do you have
evidence that leaving order of evaluation arbitrary is a performance
enabler?>>

It is always hard to get specific data across the complete spectrum of
application domains. IBM comes closest to having the necessary trace
data to do this kind of study, but that data is closely held.

Obviously it is easy to construct examples where it can make a big difference.
For example, consider:

   a + f(x)

If you demand strict left to right evaluation in a language with unrestricted
side effects, then the code has to load and save the value of A over the
function call, just in case the function call disturbs the value of A.

Certainly you will see an effect on the Specmarc if you constrain the order
of evaluation.

The real point is the following.

We know that constrainining the order of evaluation will hurt the performance
of some code.

We know that constraining the order of evaluation will only affect code that
uses side effects in a particularly nasty way.

We don't want people writing code of that kind anyway. However, without
banning side effects completely, a bad idea (*), we don't know any easy
way of disallowing the "bad" side effects.

We don't feel like damaging the efficiency of code just for the benefit of
those who want to make nasty use of side effects.

On the contrary, leaving the order of evaluation undefined will actively
discourage the use of such side effects, a good thing!

(*) everynow and then, someone wants to ban side effects completely in
functions (some people even want to ban functions, if I remember right,
one of Per Brinch Hanson's simplified Pascal-like languages went in this
direction).

However, this is a bad idea, which, once the full issues are examined, never
gets more than a splinter of support. The trouble is that there are many
legitimate uses for functions with side effects, an obvious example among
many being the use of memo functions.