[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mathematical models



|   Date: Thu, 5 Jun 1997 12:35:27 -0400
|   From: Jeffrey Mark Siskind <qobi@qobi.nj.nec.com>
|   Subject: Re: mathematical models
|   
|   I always understood the motivation for leaving argument evaluation order
|   unspecified to be the desire to allow parallel argument evaluation, not the
|   desire to allow optimizaion by reordering. But parallel argument evaluation is
|   even weaker than unspecified argument evaluation order. Under parallel
|   argument evaulation, the following expression
|   
|   (let ((x 0))
|    (+ (begin (if (zero? x) (set! x 1)) x)
|       (begin (if (zero? x) (set! x 2)) x)))
|   
|   could yield 3 which it could not do under any unspecified (applicative)
|   argument evaluation order, even one that allowed each call from a given call
|   site to have different argument evaluation order.
|   
|   Mind you, I agree with Henry that it is better to specify argument
|   evaluation order and require the compiler to determine when it is
|   safe to evaluation arguments in parallel. I'm just pointing out
|   one possible interpretation for the motivation behind the current
|   wording.

If I recall correctly, the original reason for leaving the order of
argument evaluation unspecified was that implementations did them in
different orders at the time of the Brandeis meeting (MIT Scheme has
traditionally done it right-to-left by default, others treated the
operator specially).

The recent reports and standard are far more ambitious than the
original report (probably a good thing), a large part of whose goal
was not so much to provide interoperability (although it was a goal to
varying degrees, depending on the participant) but to provide a common
language so that we could _read_ each other's code.

Hence this issue was not terribly controversial.  Parallel evaluation
was outlawed following a comment by Bert Haltstead that it was
hopeless in the absence of synchronization primitives, and we did not
want to get into that.

It might be wise these days to mandate the order of argument
evaluation to be left-to-right, but I have a hard time believeing that
this is an important issue (especially vis-a-vis records, exceptions,
etc.).

Anyone interested in proving theorems about programs (the only
argument raised for mandating it so far) can just choose such an
evaluation order and make it a big footnote at the start of his/her
paper.  Portable programs won't be affected since they should tolerate
such a choice.

An argument that would carry more weight in my mind would be an
argument about this being a real rather than perceived source of
portability problems.

The only instance of this that I know that semi-regularly trips users
is not so much the order of argument evaluation, but an unnecessary
consequence of it, namely that in some implementations MAP applies its
procedure argument to the last element of the list first, then to the
next-to-last, etc., and finally to the first.  This, of course, can be
fixed independently of the more general problem.