Multiple values, revised proposal

[Allan C. Wechsler <ACW@RIVERSIDE.SCRC.Symbolics.COM>]

    Date: Fri, 6 Nov 1992 14:40 EST
    From: meehan@src.dec.com

[From the book:]

	If the _init_ produces more values than there are _variable-names_, 
	the extra values are ignored.  If the _init_ produces fewer values 
	than there are _variable-names_, then the extra variables are 
	bound to #f.

    Proposal (part 1 of 2): Delete the second sentence.

    1. Ignoring extra values corresponds to a function's ignoring some 
    of its parameters, which is common in all languages.  

Just because everyone else does is wrong doesn't mean we can't get it
right.  If it were good for functions to ignore extra arguments, we
would define them all to do so.  But we don't -- instead, we have
too-many-args errors.

Ignoring extra values in BIND might be OK -- I don't happen to think so
-- but it can't be for the reason cited, that it's like functions
ignoring extra arguments.
							  
							  *Supplying* 
    extra values, on the other hand, seems to me to be a bad idea.

Agreed.

    2. This eliminates the need for VAL1 (a hypothetical syntax form 
    for discarding all values but the first), and we can once again write 

	    (+ (floor a) b)

I say, the current floor should be renamed, say (I don't care) to
FLOOR-AND-REMAINDER, and then define FLOOR to return one value.  Then
you can write (+ (floor a) b) also.

    since the second value is now ignored, and

	    (begin ... last-form)

    where ALL the values prior to _last-form_ are ignored.

BEGIN and kin could easily be defined to be tolerant of multi-valued
forms in its body.

(The following is not a very strong opinion.

I vaguely feel that the nonlast operands of BEGIN should be required to
return zero values.  An operator named something like FOR-EFFECT could
be introduced to help.

This is based on an intuition that we would learn something important --
I'm not sure what -- by being forced to say what to do with each value.
The tacit disposal of extra values just feels mildly pernicious to me.)

    Proposal (part 2 of 2): Add multiple-value-call.

Agreed.

    My earlier suggestion that BIND should allow #key and #next is really 
    just a way of providing an alternate syntax for anonymous methods.  

I still think, for consistency and symmetry, that the BUTLAST of a
BIND-clause should be, exactly, a parameter list.

    So let's add a multiple-value-call to Dylan.  It should NOT, however, 
    be like Common Lisp's, which allowed an arbitrary number of multiple-valued 
    expressions [...]

Agreed.