[plt-scheme] Why multiple values?

On 12/25/06, Corey Sweeney <corey.sweeney at gmail.com> wrote:
>
>
> On 12/24/06, Carl Eastlund <cce at ccs.neu.edu> wrote:
> >
> > Scheme has multiple inputs without resorting to lists (for functions
> > of fixed input size), so having the same thing for outputs isn't
> > really arbitrary or irrelevant.
>
> heh.  Multiple inputs is generally a arbitrary syntax too.  I basically see
> "(define (my-function a b c) {blah}))" as syntactic sugar for:
>
> "(define my-function (lambda (a) (lambda (b) (labmda (c) {blah}))))"

True, in some sense all syntax is arbitrary.  But multiple parameters
and multiple values are fairly direct ways of having multiple inputs
and outputs, whereas lists add an extra level of indirection.  It's a
subjective distinction, I freely admit.

> >  Lists (linear, arbitrary-size,
> > usually homogenous data structures), on the other hand, are not a
> > close fit (for flat, fixed-size, often heterogenous function outputs).
> >
> > Anyway, this isn't (just) an efficiency issue.  It's a matter of what
> > the programmer can express.  Multiple values says "this program
> > outputs these two things".  Lists say "this program outputs a list".
>
> I think were settled on the effiency issue, but I'm not seeing the
> non-effencity issue in this one.  Are you saying that when i have a set of
> numbers, that i'm actually saying "i have a set of numbers, not a list of
> numbers with special set properties added to them"?  I.E. like we should add
> set as a new primative because I want to name it differntly then "list of
> numbers with special set properties"?  If we've discarded effencicy issues,
> then we shouldn't need such a thing, right?

Yes, I definitely believe that having abstract data types is
important.  It is important to think of a list as a list, a set as a
set, a graph as a graph, and so forth.  If you always interact with
the representation directly, program design becomes very sloppy.  By
analogy, I'm also glad Scheme has a mechanism for multiple function
outputs that isn't just "a list".

-- 
Carl Eastlund