Multiple-Value implementations

[JONL at PARC-MAXC]

Apologies for not being able to reply as fast and prolifically
as others on this issue (still "snowed under" from house buying etc),
but I think the VAX/NIL method of handling multiple values should
be considered.  It has the virtue of being incredibly more
siimple than the summary you suggested, and the minor disadvantage
that MVPROG1 is slightly more expensive than it would be in a stack-
oriented implementation.

One machine register is dedicated to communicating back the number
of values returned by any function.  This is the only failing of the
MacLisp "add-on" macro scheme -- it was judged to be too expensive  to
the non MV user to have every function, including built-in system
functions, take the time (adn space!) to do this; besides, all compiled
code would be invalidated should such a demand be enforced.  

But back to the to the topic: on the VAX, the function-exit sequence includes
a two-byte instruction to set the number of values being returned.  Thus
(COND ((FOO) 'A) (T (VALUES 'B 'A)))  would have two slightly different exit
sequences (if this form were the return-value of a function).  All values
are returned in a "value-return" vector; and as Moon rightly pointed out,
having the first location of this conceptual vector be the register where
single-value function results would *normally* be found means that non-users
of the MV stuff pay only the two-byte penalty (this is truly zilch on the VAX,
considering its funciton call overhead, and it ought to be so on the PDP10).
Since this is not a stack protocol, then a tail-recursive instance of MVPROG1 must
be compiled in such a way as to save-and-restore the active value-return vector;
the cost of this may not be zilch (that is, it may actually be measurable), but
then how often and how important is this case?

The compiler need not be more clever than to "fold-out" lexical instances of
apparent mv usage.  Callers who want exactly one value from a function call need
not be perturbed at all (unless  you want to provide run-time checking for the
case of zero arguments returned).  Sume support might be given to the interpreter so 
that it not actually cons-up-into-a-list the multiple values returned -- such
as using resource-allocated scratch vectors or whatnot; perhaps some syntax is
needed whereby a "scratch list" can be given to MULTIPLE-VALUE-LIST.  [Unfortunately,
not all of these ideas got integrated into VAX/NIL before the mail development
group dissolved -- it was just using the MacLisp-like macros last time I checked --
but most of them had been coded and tested out.  It  may still be at what
you called "stage 1".]

I prefer the notion of disconnecting any rigid link between caller and callee
on this mater -- there is no m ore reason why returning multiple-values when not
explicitly "called for" is bad than there is reason to proscribe value-returning
functions from being called "for effects".  Like Moon pointed out in reply to
Fateman's concern: it's better to produce the multiple valuues even when not
wanted than it would be to produce some gross structure that had to be "torn apart"
at run time to get at the one value wanted.