Email list hosting service & mailing list manager

Re: RECEIVE vs. LET-VALUES John David Stone (02 Jul 1999 19:08 UTC)
Re: RECEIVE vs. LET-VALUES Lars Thomas Hansen (02 Jul 1999 19:47 UTC)
Re: RECEIVE vs. LET-VALUES sperber@xxxxxx (03 Jul 1999 14:10 UTC)

Re: RECEIVE vs. LET-VALUES Lars Thomas Hansen 02 Jul 1999 19:47 UTC

>From: John David Stone <xxxxxx@math.grin.edu>
>
>        So, expanding RECEIVE, the LET-VALUES version is really
>
>            (define-syntax let-values
>              (syntax-rules ()
>                ((let-values (formals expression) body ...)
>                 (call-with-values (lambda () expression)
>                                   (lambda formals body ...)))))
>
>that is, exactly like RECEIVE except that every LET-VALUES-expression must
>have an additional pair of parentheses around the <formals> <expression>
>part.

Yes.  It would have been courteous of me to point that out in the first
place.

>        The arguments for the LET-VALUES syntax are compatibility with
>MzScheme and, I suppose, a sense that bracketing the binding part separates
>it more cleanly from the body of the expression.

LET-VALUES is a less obscure name than RECEIVE, in my opinion.

Also, LET-VALUES is compatible not only with MzScheme but with
MzScheme's LET-VALUES syntax.  Systems other than MzScheme will be able
to provide the full-blown LET-VALUES rather than the more limited form
that's discussed here, which I think is a point in favor of using
LET-VALUES over RECEIVE.

>The argument against it
>is that the parentheses around the binding part are pure sugar, always
>present and never needed to resolve any ambiguity.

And also that an SRFI-8 compatible and backwards-compatible LET-VALUES
in MzScheme will be allowable with 1, 2, or 3 opening parentheses, which
is sort of ugly, though I don't think there are any ambiguities in
deciding what an expression means.

--lars