[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LET-VALUES concerns
On 14 Sep 1999 sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote
> I'm a bit concerned about the syntax of LET-VALUES:
> (LET-VALUES (<formals> <expression>) <body>)
> <Formals> should be a formal arguments list as for a LAMBDA
> expression, cf section 4.1.4 of the R5RS.
> This means
> (let-values (a <expression a single value> )
> will bind A to a list containing the single value. I believe this
> will likely be a common mistake producing an unexpected result.
Alternatively, it allows the programmer to evaluate expressions that
return a variable number of results, in the same manner that
(let-values ((a b c . d) <expression>)
allows one to evaluate expressions that return at least three results.
Your change either suggests a special case for expressions that returns
a single value (obviously undesirable, as the meaning of
(let-values (a <expr>) ...)
would depend on the number of values returned by <expr>), or would
prohibit outright LET-VALUES to bind a variable to a list containing the
remaining unmatched return values. I'll happily concede that returning
a variable number of results is not something I do every day, but
I don't mind admitting the possibility that it's occasionally useful.
> MzScheme's LET-VALUES requires <formals> to be parenthesized.
MzScheme's LET-VALUES does not allow LET-VALUES to bind a variable to a
list containing the remaining unmatched return values; the number of
values returned by an expression must be known by the receiving form.
> I would also like to see LET-VALUES allow more bindings to be
> consistent with LET.
I considered that and decided that I very rarely use nested LET-VALUES
as specified above, thus the extra level of parentheses you'd get when
you allow that (ie., clutter) didn't seem worth the benefit.
With regard to the compatibility of my proposed LET-VALUES and
MzScheme's LET-VALUES, observe that MzScheme's let-values requires a
structure of the form
(let-values ([(i1 i2 ...) expr) ...) ...)
whereas my let-values requires a structure of one of the forms
(let-values (i1 expr) ...)
(let-values ((i1 i2 ... ) expr) ...)
(let-values ((i1 i2 ... . in) expr) ...)
that is, they can be distinguished syntactically and an implementation
can support both. (As with C++, it may be a mistake to assign meaning
to too many forms where one is a simple mistyping of the other, however :-)