Re: Multiple values in Dylan

[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.  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.

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.

    As for worrying about extra return values, I agree that the caller should
    not need special operations to get rid of excess values IF the callee
    agrees that the extra values are safely able to be considered optional.

    In other words, just as a callee may specify that a tail end of given
    arguments are optional, it might also specify that a tail end of its
    returned values are optional to receive.  I don't know if this technically
    improves or detracts from the overall symmetry of Jim's proposal, but it
    does put the decision about constraints on argument passing in the hands of
    the one function returning the values, rather than in each caller of it.
    
First, I don't think you can come up with a good syntax or efficient
machinery for this.  The thought of values returning a bunch of keyword
value pairs so that the caller can treat some of these things as optional
is pretty ghastly.  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.

    As for functions of zero values being very confusing in Jim's scheme:
    Scott, could you give some examples?

Sure:

(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.

(+ (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'll take the occasional arbitrary #f any day over this sort of nonsense.

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.  And it would be
nice for a called function to have some way of detecting how many returns
its caller actually wants, so VALUES can avoid wasting effort calculating
and pushing extra values when they are just going to be discarded.  But
perhaps the SSC ("sufficiently smart compiler") can do that sort of thing
for you.

-- Scott
===========================================================================
Scott E. Fahlman			Internet:  sef+@cs.cmu.edu
Senior Research Scientist		Phone:     412 268-2575
School of Computer Science              Fax:       412 681-5739
Carnegie Mellon University		Latitude:  40:26:33 N
5000 Forbes Avenue			Longitude: 79:56:48 W
Pittsburgh, PA 15213