[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multiple values, revised proposal
- To: meehan@src.dec.com
- Subject: Re: Multiple values, revised proposal
- From: moon (David A. Moon)
- Date: Fri, 06 Nov 92 17:13:40 EST
- Cc: info-dylan@cambridge.apple.com
> Date: Fri, 06 Nov 92 11:40:50 -0800
> From: meehan@src.dec.com
>
> ....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.
The defaulting of missing values in BIND is to support programming styles such
as the following:
(bind ((frobby path-to-frobby (find-frobby name)))
(if frobby
;; There is one
(do-something-with name frobby path-to-frobby)
;; No frobby with that name exists
(do-something-else name)))
;; Returns two values:
;; The frobby with that name, or #f if there isn't one
;; The path by which that frobby was found
(define find-frobby (method (name)
(bind ((x ..la de dah..))
(when (umpty ump...)
(when (something something something...)
(bind ((frobby (do dah ...)))
(unless (no-good? frobby)
(values frobby (foo fah)))))))))
In your proposal find-frobby would have to be written as
(define find-frobby (method (name)
(bind ((x ..la de dah..))
(if (and (umpty ump...)
(something something something...))
(bind ((frobby (do dah ...)))
(if (no-good? frobby)
(values frobby (foo fah))
(values #f #f)))
(values #f #f)))))
or maybe as some horror show involving bind-exit. If it's okay to rely on the
"failure" path of when, unless, and cond to default to #f when one value is
being returned, then it should be okay to rely on it to default to #f #f when
two values are being returned.
I hope this clarifies for you the motivation that led to the current
definition of the semantics of multiple values in Dylan and in Common Lisp.
> At worst, the programmer was *expecting* some "actual" values,
> and really deserves to get an error about "too few values".
It's not clear to me why you think it's okay to let bind accept values of the
wrong type if the programmer doesn't put a specializer in the bind, but it's
not okay to let bind accept missing values if the programmer doesn't put a
specializer in the bind. In other words, I think missing values that the
caller was expecting are a type error and we already have a way to detect and
report type errors in bind, so we don't really need to put in another
mechanism. That's just my personal opinion.