Neil van Dyke wrote:
> Since the SRFI draft not only extends the "let" family to support
> multiple-values, but also defines useful procedures for dealing with
> multiple-values, would the extension of "set!" to multiple-values also
> be within the scope of the SRFI?

Multiple value SET! certainly fits the scope, good suggestion.
And, by the way, the same holds for multiple value DEFINE.

I am a little hesitant to include them, though.

Multiple value SET! and DEFINE are are less necessary for convenient
integration of multiple values because they are stand-alone operations;
they do not need to be mixed with the single-valued forms in one construct.
For this reason it would be acceptable to have separate operations,
e.g. named SET-VALUES! and DEFINE-VALUES, but I would still be in
favor of extending SET! and DEFINE instead of adding new operations.
[And DEFINE-VALUES exists in MzScheme already, e.g. as in
(define-values (a b) (values 1 2)) which conflicts with this SRFI's syntactic
approach.]

Now for SET! there might not be much of a problem, as you demonstrate
with your implementation. For full compatibility with LET etc. I would probably
settle for the two alterative syntactic forms:
        (set! <variable>+ <expression>)                                 and
        (set! (values <variable>* [ . <variable> ]) <expression>).

For DEFINE there is no principal problem either, at least not in the form
        (define <variable>+ <expression>).

The tricky one is

        (define (values <variable>* [ . <variable> ]) <expression>),

which would shadow the existing syntax for defining a procedure named
'values'. Including this sounds like a bad idea to me.

On the other hand, emulating multiple-value DEFINE when you need it
but you don't have it results in really ugly code (just try it).

So at the moment my tendency is to include multiple-value SET! and
the first case of multiple-value DEFINE, and forget about the second
case (with keyword VALUES) of multiple-value DEFINE because it
would be too confusing. The harm of leaving it out is limited because
it can be emulated reasonably well using (multiple-value) let.

Would be interesting to hear what other people think about this.

Btw, are there other constructs known that deal with multiple values
besides receive, let-values, and define-values?

Sebastian.