[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Multiple values in Dylan
- To: Scott_Fahlman@sef-pmax.slisp.cs.cmu.edu, email@example.com
- Subject: Multiple values in Dylan
- From: firstname.lastname@example.org (Sam Pilato)
- Date: Fri, 6 Nov 92 11:17:51 EST
- Cc: email@example.com
- In-reply-to: Scott_Fahlman's message of Fri, 06 Nov 92 02:28:10 EST
I hope there is more discussion of Jim's multiple-value proposal -- that
multiple values be passed as arguments to the current continuation --
because I think it is a good one.
I would like to reply to parts of Scott's message, in which he says:
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.
[In the current Dylan proposal,] 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.
I think that functions of zero values are very
confusing in a scheme like [Jim's].
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.
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.
As for functions of zero values being very confusing in Jim's scheme:
Scott, could you give some examples?