[R6RS] Syntax for multiple values

[dyb at cs.indiana.edu]

> I just finalized Sebastian Egner's SRFI 71, and I have to admit I like
> it better than LET-VALUES.  Specifically, it avoids the triple opening
> paren in the common case, and doesn't require me to switch from LET to
> a new binding form when multiple values enter the picture---thus, it
> has better "upgrade continuity."
>
> Opinions?

I assume you're referring just to the let syntax and not the uncons,
etc., procedures and values->list, values->vector syntaxes.

I find the (values ...) binding syntax ugly and would prefer not to
consider it further.  (Why stop at values, anyway?  Why not allow cons
and vector and make-foo, etc.?)  The (let ((x1 x2 ... expr) ...) body)
syntax seems somewhat reasonable.  I'm concerned, however, that it will
be confusing: people might think that the "expressions" after the first
variable are treated as an implicit begin and be surprised that this
isn't the case.  And while it looks okay for short variable names and
rhs expressions, the (let ((x1 x2 ... expr) ...) body) syntax is going
to look strange no matter how it's pretty-printed when the names and/or
expr are long enough that the binding is split across multiple lines.

For these reasons, I actually like the extra parens in let-values.
If one uses square brackets around the bindings, it's not three open
parens in a row but a much more readable paren-bracket-paren for the
first and bracket-paren for the others.

If we want to extend let rather than add let-values, I suggest that we 
go with

   (let ([lhs expr] ...) body)

where

   lhs -> var | (var ...)

This also has better upgrade continuity than let-values, and it avoids the
potential confusion and formatting difficulties of the SRFI 71 proposal.
It doesn't extend gracefully to a single-variable rest interface, but
I don't think that handling arbitrary numbers of return values is all
that important.  I've more often wanted the consumer to be a case-lambda,
e.g., accept say 2 or 3 values rather than an arbitrary number of values,
and none of the proposals allow that.  I'm happy to use call-with-values
or with-values in either case.

Kent