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

Re: Multiple values in Dylan



Jim,

After thinking about your multiple-value proposal for a while, I've decided
that I really don't like it.  (This is the proposal that multiple values be
passed as arguments to the current continuation.)  To me the model
currently proposed for Dylan seems exactly right: not sloppy, not
inefficient, and much less likely to result in programmer errors than your
model.

I like the idea that, under normal circumstances, every function returns
exactly one value.  This is clear, simple, and intuitive.  It reduces the
cognitive load on the programmer.

A few functions -- a small minority -- produce several values that are
worth returning.  Often there is a single primary value and some other
values that are only of interest to a few callers.  If the called function
is prepared to return these extra values, and if the caller is interested
in receiving them, I think it's fine to have a mechanism that does this
without consing.  But I like the idea that this is a special return
protocol that you have to explicitly request, in Dylan's case by using the
multiple-value syntax of BIND.  If you don't do that, you can count on
getting back exactly one value.  You don't have to worry about any extra
return values that might pop up, and you don't have to clutter up your code
with special operations that get rid of any excess values.

Your scheme has a certain elegant symmetry to it.  Multiple return values
are the rule, not the exception.  The caller must know exactly what values
the callee will return, just as it must know how many arguments the callee
accepts.  If a #key protocol is used for the return values, the caller must
know exactly what keywords the callee is allowed to return.  I think that
this puts a significant extra load on the programmer, for very little gain.

Finally, I don't share your dislike of #f as the "I've got nothing interesting
to return" value.  I think that functions of zero values are very
confusing in a scheme like yours.

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