Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!news.cs.indiana.edu!hieb@heston.cs.indiana.edu
From: hieb@heston.cs.indiana.edu (Robert Hieb)
Newsgroups: comp.lang.scheme
Subject: Re: Order of evaluation (was Re: evaluating () should be an error
Message-ID: <1991Apr5.110615.20429@news.cs.indiana.edu>
Date: 5 Apr 91 16:06:06 GMT
References: <1991Mar26.224805.23381@cs.ubc.ca> <6260003@otter.hpl.hp.com> <JINX.91Apr3231149@chamarti.ai.mit.edu>
Organization: Computer Science, Indiana University
Lines: 54

jinx@zurich.ai.mit.edu (Guillermo J. Rozas) writes:

>I'm just curious, but would all of you who advocate for fixing the
>order of argument evaluation accept the following order:

>All the even numbered arguments are evaluated first from right to
>left, and then the odd numbered arguments are evaluated from left to right.

>It would make all implementations consistent, it might make the task
>of those who care about proving theorems simpler (they seem to claim
>that a fixed order does), and would probably prevent people from
>abusing the order of argument evaluation, so it seems to have all the
>properties that we all want, except for freedom to the compiler.

I'll bite.  In fact, I will take it as a serious suggestion.

No. It would be perverse joke at the expense of those who must actually
use or explain the order of evaluation (implementors, provers,
instructors, authors).

However, I would be happy with a right-to-left evaluation order.  This
would suggest strongly that the (unavoidable!) order of evaluation of
the procedure and arguments on procedure call is not meant to be used
for sequencing.  Only the perverse would do so.

This would also tend to catch reliance on argument evaluation order.
It is natural for a naive programmer (and who isn't at times?) to
assume a left-to-right order of evaluation.  However, programs that
actually depend on such an order wouldn't work, and thus the dependency
would be flushed out.

This reflects the trend that seems to be evolving with respect to
unspecified return values---returning some "useless," but consistent,
value.  Although there is no way to prevent the use of such a value,
again only the perverse would do so.

As an example of the sort of program where evaluation order can be
important, consider a program that uses pseudo-random numbers.  One
might innocently write:

      (alpha (random) (random))

Unfortunately the mysterious:

      (let ([r (random)]) (alpha (random) r))

is necessary if one wishes to ensure that the program will be
consistent across different implementations or even different versions
of the same implementation.

If Olivier Danvy is listening out there, he might wish to relate his
sad tale of the difficulties he encountered due to the interaction
between "gensym" and variant evaluation orders using a single version
of a single implementation.