Re: Multiple values for R4RS.

[Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>]

    [1] Do you think VALUES and APPLY-VALUES as defined are controversial?
Yes.
    [2] Do you think VALUES and APPLY-VALUES as defined reflect existing
    practice?
Yes.
    [3] Do you think VALUES and APPLY-VALUES as defined prohibit the
    future inclusion of ACCEPTS? or some other proposal to deal with
    incompatiable arities?
No, though this seems somewhat irrelevant.
    [4] Do you believe VALUES and APPLY-VALUES should be excluded from
    Scheme solely because there is no agreement on how to deal with
    incompatiable arities?
No.

For what it's worth, I would not endorse the inclusion of VALUES and
APPLY-VALUES as proposed. Here are my suggestions for correcting it:

I would invert the order of arguments.   I think this will feel more
natural.  APPLY, normal function call, MAP, etc. all work this way.

If you cannot bring yourself to change the order, you should definitely
remove the morpheme `APPLY' to avoid confusion with argument conventions
for the APPLY function.  Programmers are likely to model the
values-yielding argument to APPLY-VALUES as a generalized variant of the
list-to-spread last argument to APPLY, and then to wonder why the two
functions take their `other' argument in opposite places.

In fact, I think this function is more closely related to
CALL-WITH-CURRENT-CONTINUATION than to APPLY, and that the naming should
reflect that.  I think a name like CALL-WITH-RESULTING-VALUES (or just
CALL-WITH-VALUES, though that's less descriptive) would be better.

In effect, what this operator does is to splice a new function into the
continuation chain.  As such, something like INTERPOSE-CONTINUATION or
ENCAPSULATE-CURRENT-CONTINUATION (well, not quite) or 
COMPOSE-CURRENT-CONTINUATION (my personal favorite, for `symmetry' with
T's COMPOSE) would also be appropriate.

RECEIVE-VALUES is clearly better than APPLY-VALUES in my mind, but it
still leaves you feeling like it should be a special form that magically
picks up values resulting from the second form, rather than something
which takes a normal functional argument. That's the main reason why I
think something with the morpheme `CONTINUATION' in it would be best.

Although these are syntactic rather than semantic issues, I consider
them important to get right.  But modulo the syntax stuff, I strongly
favor the introduction of the proposed level of functionality into R4RS.

By the way, while I'm at it, I don't much like the name VALUES because
it looks yucky for the 1-argument case.  Since RETURN is problematic, I
think I would prefer YIELD over VALUES.  But I can live with either if
it comes to it.

Also, regarding ACCEPTS?, just so I'm on the record about it, I think a
predicate that took a continuation (or even an arbitrary function) and
an integer and told you if that number of arguments was suitable.  I
think the name ACCEPTS? is too short and too general for so specific a
purpose.  I would rather a longer, less generic sounding name.  But I
have no conflict with the idea of this kind of functionality.