[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


My view of the multiple value issue is that returning multiple values is
more like a function call than like a function return.  One cannot use
multiple values except in those cases where they are caught and spread
into variables via a MVLet or whatever.  Thus, (f (g) (h)) will ignore all
but the first values of g and h in this context.  In both the function
call and multiple value return cases the procedure that is to receive
values does not know how many values to expect in some cases.  In
addition, I believe that it is important that a function, if it can return
more than one value, can return any number it likes, and that the
programmer should be able to capture all of them somehow, even if some
must end up in a list.  The Lisp Machine multiple value scheme cannot do
this.  If we buy that it is important to capture all the values somehow,
then one of two things must happen.  First, the syntax for MVLet has to
allow something like (mvlet (x y (:rest z)) ...)  or (mvlet (x y . z)
...), which is close to the LAMBDA (or at least DEFUN-LAMBDA) syntax,
which means that it is a cognitive confusion if these two binding
descriptions are not the same.  Or, second, we have to have a version
like (mvlet l ...) which binds l to the list of returned values etc. This
latter choice, I think, is a loser.

Therefore, my current stand is that we either 1, go for the decision we
made in Boston at the November meeting, 2, we allow only 2 values in the
mv case (this anticipates the plea that it is sure convenient to be able
to return a value and a flag...), or 3, we flush multiple values
altogether.  I find the Lisp Machine `solution' annoyingly contrary to
intuition (even more annoying than just allowing 2 values).