[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

This page is part of the web mail archives of SRFI 11 from before July 7th, 2015. The new archives for SRFI 11 contain all messages, not just those from before July 7th, 2015.

*To*: srfi-11@xxxxxxxxxxxxxxxxx, sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx*Subject*: Re: LET-VALUES concerns*From*: Lars Thomas Hansen <lth@xxxxxxxxxxx>*Date*: Mon, 01 Nov 1999 10:34:40 -0500*Cc*: lth@xxxxxxxxxxx

On 14 Sep 1999 sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote > I'm a bit concerned about the syntax of LET-VALUES: > > (LET-VALUES (<formals> <expression>) <body>) > Syntax > <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 :-) --lars

- Prev by Date:
**Re: why not 3 different SRFIs** - Next by Date:
**Re: Existing implementations** - Previous by thread:
**LET-VALUES concerns** - Next by thread:
**why not 3 different SRFIs** - Index(es):