This page is part of the web mail archives of SRFI 86 from before July 7th, 2015. The new archives for SRFI 86 contain all messages, not just those from before July 7th, 2015.
Sebastian Egner <sebastian.egner@xxxxxxxxxxx> writes:
> Now the rationale for <unspecified order> in procedure
> application is...
... the topic of wonderful flame wars, as can be verified by a
quick search through comp.lang.scheme.
I hope they are not repeated here. :-)
> ...not really obvious to me, either. My guess:
>
> a) Theory people like it big time because the order of
> evaluation of argument expressions is a non-essential
> feature of the model, and would have to be introduced
> into the semantics artificially afterwards.
Actually, it's theory people who really dislike the unspecified
order, since for program verification, you have to check every
possible order to prove correctness.
> b) Implementations are free to choose the internal
> representation of argument lists, and hence also the
> algorithms for evaluating these expressions.
Some people argue that this can lead to efficiency gains.
But it's basically a matter of belief.
If you think that
(foo (bar) (baz) (qux))
and
(let ((fnord (baz)))
(foo (bar) fnord (qux)))
should be equivalent, you're in the "unspecified OOE" camp.
If you prefer to be able to rely on the order for interdependence
between arguments - like using DISPLAY in the arguments - or if
you're into program verification, you're in the "left-to-right
OOE" camp.
> Anyhow, since the existing implementation do not agree on the
> order of evaluation of arguments the chance that it will become
> fully specified in R^nRS, for some n > 5, are zero.
To quote the "R6RS Status Report" from February 2006
(http://www.schemers.org/Documents/Standards/Charter/status-mar-2006.html):
| 3.6. Reaffirmations
|
| The following features of R5RS are reaffirmed for R6RS.
| [...]
| * unspecified evaluation order for applications, let bindings, and
| letrec bindings
I agree with Sebastian that, regardless of whether you are in the
l2r-OOE-camp or in the unspecified-OOE camp, being consistent with
the current and future RnRS is preferable.
If you really want a l2r ALET, call it ALET+ or somesuch.
Actually, I would also recommend using a longer name than ALET
unless the A has some specific semantic that eludes me at the
moment. MU-LET for example would be much more expressive as to the
use of the LET form.
Also, is there any reason why you define MU and NU as syntax, and
not as procedures?
Regards,
-- Jorgen
--
((email . "forcer@xxxxxxxxx") (www . "http://www.forcix.cx/";)
(gpg . "1024D/028AF63C") (irc . "nick forcer on IRCnet"))