Re: define and set! with multiple-values

[Bob Kerns <rwk@world.std.com>]

    Date: Thu, 31 Dec 92 15:01:22 EST
    From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
    
        As a programmer I like and enjoy multiple return values, it would be
        sad to see them go.
    
    I think that makes you nearly unique.  The vast majority of Common Lisp
    programmers I've talked to consider multiple values to be an ugly blot on
    the language (one of many), but a perhaps-necessary evil.
    Multiple values do make life *much* harder for implementors.
    
In my experience, they're not that much work for implementors.

However, the single most annoying fault of C (besides syntax)
is the lack of multiple values.  The two kludgy workarounds,
namely passing arguments by reference and special purupose
data-structures just to hold the return values, are both
problematic from a semantic point of view, and impose both
an expressiveness cost and a modularity cost on the caller
of a module.

The idea that functions return a single value, or (as in C)
return either zero or one value is backwards.  It's a matter
of forcing the thinking to conform to the language, rather
than having the language support thinking clearly about the
algorithm.

If the majority of CL programmers you talk do don't like
multiple-values, I have to suspect that they're mostly
your students, and you're getting a biased sample.  Because
that doesn't square with my experience at all.

(Of course, such anecdotal surveys prove nothing, other than
that we have proven nothing.  My own sample, of course, may
be biased.  It's my *opinion* that most CL programmers do
like and appreciate multiple values.  I've heard far more
complaints that they aren't subject to number-of-values
checking than to their existance.  "Everyone" seems to like
them, they just can't agree what they should do).

Speculating for a moment, perhaps why you think they make
life harder for implementors is that the language makes it
hard to do type inferencing on multiple values because it
makes it hard to declare the types of the multiple values,
and because the "NIL if not supplied" rule makes things
into unions.  I claim that's not multiple values in the
abstract that causes the problem, but rather the specific
semantics in CL, and this could be fixed without throwing
out the baby with the bathwater.  (I'm not sure the optimizations
you'd gain are worth the trouble, however.)