[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
multiple return values (LONG)
> (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.
> (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
> 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
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.