Multiple Values

[Scott.Fahlman at CMU-10A]

I hate to rock the boat, but I would like to re-open one of the issues
supposedly settled at the November meeting, namely issue 55: whether to
go with the simple Lisp Machine style multiple-value receving forms, or
to go with the more complex forms in the Swiss Cheese Edition, which
provide full lambda-list syntax.

My suggestion was that we go with the simple forms and also provide the
Multiple-Value-Call construct, which more or less subsumes the
interesting uses for the Lambda-list forms.  The latter is quite easy
to implement, at least in Spice Lisp and I believe also in Lisp Machine
Lisp: you open the specified function call frame, evaluate the
arguments (which may return multiples) leaving all returned values on
the stack, then activate the call.  The normal argument-passing
machinery  (which is highly optimized) does all the lambda grovelling.
Furthermore, since this is only a very slight variation on a normal
function call, we should not be screwed in the future by unanticipated
interactions between this and, say, the declaration mechanism.

Much to my surprise, the group's decision was to go with all of the
above, but also to require that the lambda-hacking forms be supported.
This gives me real problems.  Given the M-V-CALL construct, I think
that these others are quite useless and likely to lead to many bad
interactions: this is now the only place where general lambda-lists have
to be grovelled outside of true function calls and defmacro.  I am not
willing to implement yet another variation on lambda-grovelling
just to include these silly forms, unless someone can show me that they
are more useful than I think they are.

The November vote might reflect the notion that M-V-LET and M-V-SETQ
can be implemented merely as special cases of M-V-CALL.  Note however,
that the bodies of the M-V-LET and M-V-SETQ forms are defined as
PROGNs, and will see a different set of local variables than they would
see if turned into a function to be called.  At least, that will be the
case unless Guy can come up with some way of hacking lexical closures
so as to make embedded lambdas see the lexical binding environment in
which they are defined.  Right now, for me at least, it is unclear
whether this can be done for all Common Lisp implementations with low
enough cost that we can make it a required feature.  In the meantime, I
think it is a real mistake to include in the language any constructs
that require a successful solution to this problem if they are to be
implemented decently.

So my vote (with the maximum number of exclamation points) continues to
be that Common Lisp should include only the Lisp Machine style forms,
plus M-V-CALL of multiple arguments.  Are the other forms really so
important to the rest of you?

All in all, I think that the amount of convergence made in the November
meeting was really remarkable, and that we are surprisingly close to
winning big on this effort.

-- Scott