Re: MVLet

[Fahlman at CMU-20C]

I agree with DLW that we must retain M-V-LIST.  I never meant to exclude
that.

As for RPG's latest blast, I agree with some of his arguments but not
with his conclusions.  First, I think that the way multiple values are
actually used, in the overwhelming majority of cases, is more like a
return than a function call.  You call INTERN or FLOOR or some
user-written function, and you know what values it is going to return,
what each value means, and which ones you want to use.  In the case of
FLOOR, you might want the quotient or the remainder or both.  The old,
simple, Lisp Machine forms give you a simple and convenient way to
handle this common case.  If a function returns two often-used values
plus some others that are arcane and hard to remember, you just catch
the two you want and let the others (however many there are) evaporate.
M-V-LIST is available to programs (tracers for example) that want to
intercept all the values, no matter what.

Having said that, I agree that there are also some cases where you want
the catching of values to be more like a function call than a return,
since it may be somewhat unpredictable what is going to be bubbling up
from below, and the lambda list with optionals and rests has evolved as
a good way to handle this.  I submit that the cause of uniformity is
best served by actually making these cases be function calls, rather
than faking it.  The proposed M-V-CALL mechanism does exactly this when
given one value-returning "argument".  The proposal to let M-V-CALL
take more than one "argument" form is dangerous, in my view -- it could
easily lead to impenetrable and unmaintainable code -- but if it makes
John McCarthy happy, I'm willing to leave it in, perhaps with a warning
to users not to go overboard with this.

So I think RPG has made a strong case for needing something like
M-V-CALL, and I propose that M-V-CALL itself is the best form for this.
I am much less convinced by his argument that the multiple value SETQing
and BINDing forms have to be beaten into this same shape or thrown out
altogether.  Simple forms for simple things!

And even if RPG's aestheitc judgement were to prevail, I would still
have the problem that, because they have the semantics of PROGNs and not
of function calls, the Lambda-list versions of these functions would be
extremely painful to implement.

As I see it, if RPG wants to have a Lambda-binding form for value
catching, M-V-CALL gives this to him in a way that is clean and easily
implementable.  If what he wants is NOT to have the simple Lisp Machine
forms included, and to force everything through Lambda-list forms in the
name of uniformity, then we have a real problem.

-- Scott
-------