multiple return values (LONG)

[David Bartley <bartley%home%ti-csl.csnet@RELAY.CS.NET>]

>     (1) I agree with ALAN and Jinx that it seems pretty useless to specify
>     a multiple value capability and not go beyond Will's alternative #1.
>     Since I intend to implement Common Lisp on top of Scheme, I will want
>     to extend the essential capability anyway.  (Are ALAN and Jinx arguing
>     for #2 or #3?)
> I like #2.  More about this below.  

JINX makes a pretty good case for #2 and I'm persuaded.  More below.
Scratch the term "useless"---standardizing on #1 at least gives us a
common basis for our various extensions.

>     (4) It seems to me that the hairiest part of the multiple value
>     "feature" in Common Lisp is MULTIPLE-VALUE-PROG1.  Something like this
>     [...]
>
> I think it is worth thinking about, but given that the above is
> sufficient, I don't think there is a need to standardize.

OK.

>     (5) JAR finds the proposed feature "to be pretty unuseable unless
>     there is some syntactically sugared way to use RECEIVE-VALUES."  If
>     this is true, I think we must agree on what sugar to add.  What's the
>     point of standardizing on something that is too cryptic to be used by
>     anyone?
>
>     I like T's RECEIVE [...]
>
>     If we keep the name RECEIVE-VALUES, then the name RECEIVE is ok here,
>     but I would prefer something like MULTIPLE-VALUE-LET.
>
> What about MULTIPLE-VALUE-BIND?  The syntax is not like LET at all,
> and it really is similar to the CL construct.

Upon reflection, I wonder if there really is a problem.  Does anyone
else feel that the proposal is "pretty unuseable unless there is some
syntactically sugared way to use RECEIVE-VALUES" or that it is "too
cryptic"?  I don't.

>     (6) Let's get down to brass tacks and argue about names! [...]
>
> I don't care much about the names of procedures, but I agree with GLS.
> What's wrong with VALUES?  Another possibility for RECEIVE-VALUES is
> MULTIPLE-VALUE-COMPOSE, or even, CALL-EXPECTING-MULTIPLE-VALUES.

OK.  I like VALUES or MULTIPLE-VALUES instead of RETURN-VALUES; both
avoid the imperative "return" that seems to imply some kind of throw.

I like WITH-VALUES or CALL-WITH-VALUES or CALL-WITH-MULTIPLE-VALUES
instead of RECEIVE-VALUES.  The problem with "RECEIVE-" is that ones
first guess at the meaning of (RECEIVE-VALUES ...) might be that it
"receives" multiple values and returns them, rather than disposing of
them by a further call.  The problem with "CALL-" is that it isn't
clear which of the two procedure arguments the "call" refers to.  The
"CALL-" in CALL-WITH-MULTIPLE-VALUES refers to the second argument.
The "CALL-" in CALL-EXPECTING-MULTIPLE-VALUES refers to the first.

> Well, here is my argument for proposal #2:
>
> I think that there is a very important symmetry between procedure
> invocation and continuation invocation.  Indeed, if the code is CPS
> converted, they become the same thing.

This symmetry gives us a rational basis for the whole idea, so I like
the idea of remaining consistent with it.

> [...]
> Now, wait a minute... This seems like an argument for #1, right?
>
> Well, the difference is that there are (as far as I can tell) no
> implicit procedures, but there certainly are implicit continuations,
> and the behavior can be different.
>
> The rule is as follows: an implicit continuation may be called with
> MORE values than it expects, and these extra values are ignored.  Thus
> [...]

I like the idea of defining implicit continuations to look like
(LAMBDA (X . IGNORE) ...)).

> As far as continuation objects obtained with CWCC are concerned, they
> should accept multiple arguments if the corresponding continuation
> accepted multiple values, thus [...]

This is what I was trying to accomplish with my proposal.  Thanks for
clarifying the issue.

> Having said all this, I'll also say that I'm afraid that we will not
> be able to standardize.  JAR feels relatively strongly about proposal
> #1, and I think that other people do also.  I feel relatively strongly
> agains standardizing on the CL standard, since I don't believe in the
> random NILs (or #Fs) being created on demand, so I'm therefore opposed
> to #3, and I would not be surprised if other people had their own pet
> theories.

Will's proposal was carefully worded so as to allow us to standardize
in #1, #2, or #3 and still allow those of us who want to to make
extensions compatible with Common Lisp.  I think we should make an
effort to agree on names and syntax for multiple values, preferably
using alternative #2 (but I'll accept #1 if necessary), because it at
least gives us a common base for our extensions.

In summary: I like the names VALUES (or MULTIPLE-VALUES) and
WITH-VALUES (or CALL-WITH-VALUES or CALL-WITH-MULTIPLE-VALUES).  I
like the syntax proposed by Will.  I prefer alternative #2 but will
accept #1 rather than lose the chance to standardize.  I see no need
for MULTIPLE-VALUE-PROG1 or syntactic sugar like MULTIPLE-VALUE-BIND.

Regards,
David Bartley