multiple values

[Jonathan A Rees <JAR@AI.AI.MIT.EDU>]

    Date: Fri, 31 Oct 86 03:23:10 EST
    From: Alan Bawden <ALAN at AI.AI.MIT.EDU>

    I don't use CL multiple values in any situation where LIST will
    suffice.  I use it just in case I want some "by-products" to be
    transparently discarded by all but a few callers.  This is why
    multiple values were added to the Lisp Machine in the first place,
    and its still the only reason I see to use it.
    ...

As Alan has tactfully pointed out to me, none of the multiple-value
features that Gary Brooks and Andy Freeman and I and others have been
talking about bear much resemblance to CL multiple values, and they are
really intended to solve a different problem.  The terminology is a
problem here; we really shouldn't be saying that these constructs do
"multiple value returns" because Lisp Machine Lisp and its derivatives
(CL) have been using that term for quite a while to mean something quite
different.  (I might have called the LM feature "extra value returns"...)
We should no more think that we're "cleaning up something CL
did wrong" than we should think that omitting optional or keyword arguments,
or macros or packages, solves the problems that those features
were introduced to address.

I agree that the RECEIVE/VALUEs feature is of marginal usefulness.  I
don't think this is the most important outstanding issue we have to talk
about; macros, modules, opaque types, tables, and even bitwise logical
operators all loom larger.  Of course, the more agreement we can get on
any feature at all, the better.

A suggestion on how to proceed: we needn't think of every discussion as
aiming towards something to be included in R^4RS.  If just 2
implementations agree on a way to do something, we have still gained
something.  We should consider creating an auxiliary document, much more
informal and open-ended than a R^nRS, describing possibilities for
standard libraries and utilities, possibly with multiple different ways
to do things if no agreement can be reached.  Unanimity may be too
stringent a requirement if this group is to make much progress....

Jonathan