Re: Order of evaluation in PUSH (& PUSHNEW)

[larus%paris.Berkeley.EDU@berkeley.edu (James Larus)]

	 Date: Thu, 21 May 87 14:19 EDT
	 From: P. T. Withington <PTW@YUKON.SCRC.Symbolics.COM>

	 I see no reason to require evaluation order of arguments when there is
	 already a mechanism to enforce it:  use LET* where evaluation order is
	 important.  A good compiler should be able to optimize away the implied
	 temporaries when the expressed evaluation order matches the
	 implementation evaluation order.

     Remember that Common Lisp is a language with side-effects, and in such
     languages there are more constraints on evaluation order than just the
     data dependencies.  With LET* you are talking data dependencies.

In discussing side-effects between the evaluation of formal arguments,
we are also talking about data-dependencies.  Taking a page from the
vector processor and multiprocessor compiler literature: a data-dependence
between two statements occurs when one statement writes a value into a
location and another statement either reads or writes this location.
This gives us three types of data-dependencies: W(rite) followed by
R(read), R followed by W, and W followed by W.

Moon is expressing the common belief that all data-dependencies are of
the first type, as for example:

	(LET* ((A (FOO))
	       (B (BAR A))) ...)

in which the first clause of the LET* statement writes a value into
the location called `a' and the second reads the same location (W-R
for short).

However, there is no fundamental difference between this example and
the following one (R-W):

	(REORDER-AND-DIE ARG (SETQ ARG 1))

The major difference between the two is that a larger group of people
would probably object to the latter example on grounds of taste.


     In any case, Scott Fahlman explained quite clearly in an earlier message
     why Common Lisp takes the stand it does.  I think that reasoning is just
     as true today as it was three years ago.

As I tried to suggest in my earlier note, there are strong reasons
apart from multiprocessor Lisps why Common Lisp's stand is an
unnecessary constraint on the language.

The status quo be better defended on two grounds: I like side-effects
and want predictability without having to introduce additional
sequence constraints like LET* and PROGN or this is a major change
that will break a lot of code.  Multiprocessors are just a
red-herring.

/Jim