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

Re: [Scheme-reports] library at file level

Taylan Ulrich B. scripsit:

> Would it be sensible to specify the behavior of the `let' family of
> syntaxes, with regard to this issue, on the basis of `begin'?
> That is, if the body of a `let' kind of form consists entirely of
> definitions, they are spliced into the enclosing scope; otherwise a
> scope is created.

That would be a considerable change from both R5RS and R6RS.  In R5RS,
R6RS, and the current draft, `let` and `let*` have bodies; that is, after
the bindings there are zero or more definitions followed by one or more
expressions (modulo the slightly different definitions of "definition"
in each standard).  The same is true in SRFI 11, R6RS, and the current
draft for `let-values` and `let*-values`, which are not present in R5RS.

But in R6RS, `let-syntax` and `let*-syntax` don't have bodies; they
accept an arbitrary sequence of forms after the bindings.  This is a
change from R5RS which the current draft doesn't adopt.  In order to
go the way you suggest, `let`, `let*`, `let-values`, and `let*-values`
would all have to be changed in the same way.

> On the other hand, I found the equivalent practice, using `let-syntax',
> very useful in a recent piece of code of mine[0]; it drastically reduced
> the repetitiveness of a series of definitions.  The only alternative I
> can think of which achieves this is to define the macro I used in the
> global scope, which would not be very nice.  

In R6RS and R7RS, such macros can be in the module scope without being
exported, which I think helps with that problem.

Why are well-meaning Westerners so concerned that   John Cowan
the opening of a Colonel Sanders in Beijing means   cowan@x
the end of Chinese culture? [...]  We have had      http://www.ccil.org/~cowan
Chinese restaurants in America for over a century,
and it hasn't made us Chinese.  On the contrary,
we obliged the Chinese to invent chop suey.            --Marshall Sahlins

Scheme-reports mailing list