Re: MVlet

[Fahlman at CMU-20C]

    1. What is that hard to implement about the MVlet thing that is not
    already swamped by the difficulty of having n values on the stack
    as you return and throw, and is also largely subsumed by the theory
    of function entry?

Function calling with hairy lambda syntax was an incredible pain to
implement decently, but was worth it.  Having multiple values on the
stack was also a pain to implement, but was also (just barely) worth it.
The proposed M-V-CALL just splices together these two moby pieces of
machinery, so is relatively painless.  In the implementations I am
doing, at least, the proposed lambda-list syntax for the other MV forms
will require a third moby chunk of machinery since it has to do what a
function call does, but it cannot be implemented as a function call
since it differs slightly.

    2. To get any variable number of values back now you have to CONS anyway,
    so by implementing it `poorly' for the user, but with
    a uniform syntax for all, is better than the user implementing
    it poorly himself over and over.

Neither the simple MV forms nor M-V-CALL would cons in my
implementations, except in the case that the functional arg to M-V-CALL
takes a rest arg and there is at least one rest value passed to it.  To
go through M-V-LIST routinely would cons much more, and would make the
multiple value mechanism totally worthless.

    3. If efficiency of the implementation is the issue, and if the
    simple cases admit efficiency in the old syntax, the same simple
    cases admit efficiency in the proposed syntax.

Yup, it can be implemented efficiently.  My objection is that it's a lot
of extra work (I figure it would take me a full week) and would make the
language uglier as well (in the eye of this beholder).

    4. Here's what happens when a function is called:
    	You have a description of the variables and how the
    	values that you get will be bound to them depending on how many
        you get.

      Here's what happens when a function with multiple values returns to
      a MVlet:
    	You have a description of the variables and how the
    	values that you get will be bound to them depending
        on how many you get.

Here's what really happens:

You know exactly how many values the called form is going to return and
what each value is.  Some of these you want, some you don't.  You
arrange to catch and bind those that are of interest, ignoring the rest.
Defaults and rest args simply aren't meaningful if you know how many
values are coming back.

In the rare case of a called form that is returning an unpredictable
number of args (the case that RPG erroneously takes as typical), you use
M-V-CALL and get the full lambda binding machinery, or you use M-V-LIST
and grovel the args yourself, or you let the called form return a list
in the first place.  I would guess that such unpredictable cases occur
in less than 1% of all multiple-value calls, and the above-listed
mechanisms handle that 1% quite well.

OK, we need to settle this.  If most of the rest of you share RPG's
taste in this, I will shut up and do the extra work to implement the
lambda forms, rather than walk out.  If RPG is alone or nearly alone in
his view of what is tasteful, I would hope that he would give in
gracefully.  I assume that punting multiples altogether or limiting them
to two values would please no one.

-- Scott
-------