Re: Multiple values in Dylan

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

    Date: Fri, 6 Nov 1992 12:47 EST
    From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU


	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
particular objection.
							       
							       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
first value.
    
[...]

			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
    zero-valued.

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.