[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
multiple return values
(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?)
(2) In his rationale, Will said "The Common Lisp position would say
that when zero values are returned to a continuation that is expecting
one value, then the symbol NIL is passed to the continuation." I
think we could specify this to be "the false value" or "the empty
list" and remain compatible with Common Lisp without having to make
the symbol NIL noteworthy in Scheme.
(3) Will's proposal does not mention CALL-WITH-CURRENT-CONTINUATION.
It seems that a continuation object should accept an arbitrary number
of arguments if we take alternative #2 or #3. If so, we could define
(RETURN-VALUES A B) to be the same as (CALL/CC (LAMBDA (K) (K A B))).
(4) It seems to me that the hairiest part of the multiple value
"feature" in Common Lisp is MULTIPLE-VALUE-PROG1. Something like this
is needed, at least "behind the scenes", if we expect DYNAMIC-WIND
(etc.) to pass through multiple values. We could express
(MULTIPLE-VALUE-PROG1 A B ...) as
(receive-values A (lambda L B ... (apply return-values L))) ,
but that is pretty expensive. Is this common enough to require
standardization so implementors could work on more efficient
mechanisms?
(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, which I understand to be defined as
(receive <formals> <m-v-expression> . <body>)
==> (receive-values (lambda () <m-v-expression>)
(lambda <formals> . body>))
The key for me is that <formals> is a complete lambda list, possibly
containing "optional" and "rest" arguments, and is not just a list of
"required" identifiers. This seems more flexible than Common Lisp's
MULTIPLE-VALUE-BIND.
If we keep the name RECEIVE-VALUES, then the name RECEIVE is ok here,
but I would prefer something like MULTIPLE-VALUE-LET.
(6) Let's get down to brass tacks and argue about names! I'm bothered
by the "return" in RETURN-VALUES. As Will pointed out, the name
RETURN would be confusing to refugees from other Lisps. However,
RETURN-VALUES still seems to imply an exit from the calling procedure.
A user might ask whether the procedure
(LAMBDA (A B C) (+ A (RETURN-VALUES B) C))
returns the sum of A, B, and C or just B? I think we all intend for
RETURN-VALUES to "return" to its caller (the middle of the body), not
to that procedure's caller. I suggest renaming RETURN-VALUES to be
MULTIPLE-VALUES.
Likewise, the "receive" in RECEIVE-VALUES seems strange; I would
expect the complementary routine to be SEND-VALUES. How about
CALL-WITH-MULTIPLE-VALUES (call/mv?) by analogy with CALL-WITH-
CURRENT-CONTINUATION (call/cc)? (I'm not sure if I'm joking!)
Regards,
David Bartley