[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multiple values in Dylan
- To: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
- Subject: Re: Multiple values in Dylan
- From: Allan C. Wechsler <ACW@RIVERSIDE.SCRC.Symbolics.COM>
- Date: Fri, 6 Nov 1992 14:30-0500
- Cc: Info-Dylan@cambridge.apple.com, samp@KURZ-AI.COM, meehan@SRC.DEC.COM
- In-reply-to: <9211061752.AA04918@brazil.cambridge.apple.com>
Date: Fri, 6 Nov 1992 12:47 EST
If in fact a small minority of functions produce several values, then
ALMOST every function returns exactly one value. That's intuitive enough
for me and my cognitive load -- I can handle the few that don't.
Sure, a good programmer can handle most anything. But the very existence
of multiple values that might pop up unbidden means that you've got one
more thing to worry about. It would be a pain to have to remember that
certain built-in arithmetic functions return a second value that you
usually don't want and that you explicitly have to flush.
I think the names of functions that return multiple values should adhere
to naming conventions that don't let you forget, for example,
FLOOR-AND-REMAINDER, or READ-CHAR-AND-EOF. Not that I'm advocating that
exact convention, but some such convention could surely answer this
It would be an
even bigger pain, when dealing with someone else's library package, to
remember how many probably-unwanted-but-maybe-useful-to-someone values the
author decided to pass back.
The author of a library package can certainly shaft you with unexpected
interfaces. No set of language design decisions is going to protect you
against this. A naming convention would help here, too.
If Meehan's proposal were adopted, rule 1 in our local style guidelines
would be that NO function should ever return other than one value unless
its name is MULTIPLE-VALUE-*, because now those additional return values
are more trouble than they are worth.
The naming convention need not be that obtrusive -- this is a straw man.
A natural result would be that most multi-valued functions would have
single-valued interfaces that you would call when you only wanted the
Second, I don't think that "optionalness" of return
values is any business of the called function. It is the caller that knows
which of these things are useful.
I agree with this.
(cons (foo a) (bar b) (bletch c))
It kind of looks like too many arguments are being passed there, and my
sophisticated syntax-checking editor just complained. But in this case
it's OK, since bar really does some side-effect and returns zero values, so
it acts sort of like a comment -- drop it in code anywhere. BAR isn't
written yet, so none of the programming tools know that it's going to be
No, you must have misunderstood Meehan's proposal. If BAR returned zero
values, it would be calling the current continuation with zero
arguments. The current continuation would signal too-few-arguments.
The compiler and your editor have not lost their license to complain
about the above expression.
(+ (foo a) (bar b) (bletch c))
How many numbers are we adding here? The correct answer in this case is
27, but you sure can't tell that by looking at the code. Turns out that
bar is not a cosntant, so it can be changed at runtime and none of this can
be open coded.
I'm worried that everyone is going to have this misimpression. Unless I
am mistaken, Meehan was not proposing that Dylan have MARVEL syntax,
where all the returned values are passed to the calling function.
Rather, the proposal states that all the returned values be passed to
the current continuation, which is quite different. In ordinary
function-argument position, the current continuation takes exactly one
argument, and it is simply an error to call it with any other number of
arguments. Thus, an expression in argument position would be
constrained to be single-valued.
I'll take the occasional arbitrary #f any day over this sort of nonsense.
I would too, but that sort of nonsense has not been proposed.
I repeat: the scheme presented in the book looks right to me. I might go
one step farther and use a separate MULTIPLE-BIND call instead of
decorating the more commonly used BIND with extra fields.
I sort of liked the expanded BIND. I even think that it should be
extended to allow #key. Thus, the "butlast" of a BIND-clause would
exactly be the parameter-list of the current continuation.