[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Multiple values, revised proposal

After reviewing the discussion on multiple values, I would like to 
propose a simpler, less stringent rule that I think more people would 
find acceptable.  In describing BIND, the book says on page 34: 

    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.  *Supplying* 
extra values, on the other hand, seems to me to be a bad idea.

    At best, it's Dylan's way of providing &AUX, which was unnecessary 
    in Common Lisp; it was yet another syntax for binding variables, 
    and it offered no additional semantics. 

    At worst, the programmer was *expecting* some "actual" values, 
    and really deserves to get an error about "too few values". 

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)

since the second value is now ignored, and

        (begin ... last-form)

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

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

My earlier suggestion that BIND should allow #key and #next is really 
just a way of providing an alternate syntax for anonymous methods.  
That is, I could write the continuation as 

    (method (a b #key ...) ...)

and I would, except that since Dylan lacks multiple-value-call, there's 
no way for me to call this method, other than the kludgey

    (bind ((#rest args mv-exp))
      (apply (method (a b #key ...) ...) args)

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, and "appended" all the results together. (Did anyone 
ever use that feature?) Dylan's should be much simpler.  Add to page 73: 

    (multiple-value-call _function_ _form_) => values      [Special form]

    This is like APPLY.  The values produced by _form_ are spread 
    out and taken as individual arguments to _function_.