[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multiple-value set!
This page is part of the web mail archives of SRFI 71 from before July 7th, 2015. The new archives for SRFI 71 contain all messages, not just those from before July 7th, 2015.
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
> 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,
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
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
(values <variable>* [ . <variable> ]) <_expression_>).
For DEFINE there is no principal problem
either, at least not in the form
The tricky one is
(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
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?