Re: define and set! with multiple-values

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

    Date: Fri, 01 Jan 93 14:20:29 EST
    From: Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU
    
        In my experience, they're not that much work for implementors.
        
    I guess it depends on how hard you want to try to squeeze out that last
    cycle or two of per-call overhead.  Implementing CL-style multiple-value
    returns with *no* added cost to calls/returns that expect/return a single
    value is difficult.

Not in my experience.  I don't mean it's *no* work for the
implementor, or that it doesn't require a little bit of thinking,
but the work required is pretty straight-forward and contained.
It's nothing compared to, doing efficient array access, or
having reasonable error messages and warnings, or making efficient
use of registers.  Of all the things a compiler-writer has to
worry about, I'd place this near the bottom of the list of
"difficult issues".

I agree that the techniques to do it with *no* added cost for
the single-value case, while simultaneously *minimizing* cost
for the multiple value case, you have to get achitecture-specific.
Those who implement portable implementations will need a small
library of techniques instead of a single technique, if they
want to take advantage of various interesting tricks you can
do to whittle down the cost of the multiple-value case.
    
        However, the single most annoying fault of C (besides syntax)
        is the lack of multiple values.
    
    I wouldn't have put this even in the top ten.  
It's a close race with the lack of lexical closures.  Both force
you to make datatypes just to communicate values between caller
and callee.
						   In any case, this is made
    much worse in C by the lack of built-in, efficient dynamic storage
    management.  In Lisp and Dylan, there is at least the alternative option of
    creating and returning a sequence.

But then you lose the advantage of declaring the return value type!

    ... FLOOR ...

    So perhaps something like the current MV system in the Dylan book is the
    best compromise after all.  I agree that we need improved declaration
    facilities for return values, and that topic is being discussed.

Ah, you made that argument for me.  Excellent.

    Personally, I'd like a separate MV-BIND form to make it visually obvious
    that multiple values are being accepted.  (Visually obvious to people, that
    is -- compilers will have no trouble telling the MV syntax from the
    single-value syntax by counting how many items live within each paren.)

I prefer the (set! (values x y z) ...) approach to the (set! (x y z) ...)
approach, for exactly this reason.

    I'm still not convinced that we need multiple values in SET! and DEFINE,
    but I'm not violently opposed to this.

I think something like this makes the significantly easier
to use, and helps to avoid cluttering the code in ways that
remind me of spurious datatypes and supplying NULL to C
by-reference arguments that you *hope* the programmer allowed
you to supply NULL to say you didn't want that silly return
value.  (A common source of bugs, I've found).