Re: multiple-value set!

[Sebastian Egner <sebastian.egner@xxxxxxxxxxx>]

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.