[R6RS] multiple-value binding

[Anton van Straaten]

dyb at cs.indiana.edu wrote:
> I'd like to revive the multiple-value binding discussion.  I believe
> there have been three basic proposals for a multiple-value binding form,
> which I've identified as 1, 2, and 3 below.  To that I'm adding a fourth.

My preferences, of the options given, are 4 > 1 > 3 > 2.

I'd also be fine with using (short) names other than LET and LET* for 
options 2, 3, and 4.

Here's my rationale for my preferences:

> 1. (let-values ([idspec expr] ...) body)
> 
>    idspec -> id | (id ...) | (id id ... . id)

I agree with Mike, and with SRFI-71, about LET-VALUES: it's clumsy when 
working with a mixture of single & multiple values.  Without a single 
form which supports such mixing conveniently, multiple values are less 
usable.  I also find the name a bit long for such a fundamental form.

> 2. (let ([id ... expr] ...) body)

This seems to violate the usual mapping between concrete and abstract 
syntax in Scheme, with a distinct list of identifiers that's not 
syntactically represented as a distinct list.

> 3. (let ([idspec expr] ...) body)
> 
>    idspec -> id | (id ...) | (id id ... . id)

I would prefer the use of multiple values to be more explicit.  In the 
case of LET-VALUES, it's expected that a list of the form "(id ...)" 
binds to multiple values, since the form name implies that.  It's also 
completely consistent, i.e. there's no special-casing for single values.

When it comes to LET, though, I prefer the explicitness (and generality) 
of #4.

It could be argued that making multiple value handling more implicit is 
a good thing, integrating it more tightly into the language.  However, 
in general, multiple values can't be treated in the same way as single 
values (as would be the case with e.g. first-class tuples), so making 
their presence implicit is misleading.

> 4. (let ([idspec expr] ...) body)
> 
>    idspec -> id | vidspec
>    vidspec -> (values . id) | (values id ...) | (values id id ... . id)

Of the four, I like this one best, although it most strongly raises the 
question of why other binding patterns aren't supported, to bind to 
values in pairs, lists, vectors, etc.  Of course, extension in this 
direction would be possible in future, which may be an advantage.

>  - Whichever option we choose, I think we should include a let* variant
>    as well.

Agreed.

>  - I'm less sure about letrec or letrec* variants.  

Omitting these is fine with me.

Anton