Marc Nieper-Wißkirchen wrote:

> P.S.: Should SRFI 147 ever become a part of (scheme base) in Larceny, I
> think it is only fair when Larceny changes the semantics for
> let(rec)-syntax as defined by SRFI 147 to the R6RS-compatible (splicing)
> semantics of Larceny.
>
> If Will could give me a hint on this, I would recode SRFI 148 more
> defensively (i.e. taking care of (let () ...) wrappers around
> let(rec)-syntax.

You could wrap a (let () ...) around every use of let-syntax or
letrec-syntax for which you want the definitions that result from
expanding the body to be limited to a new local contour.

If there are a number of those, you can define your own versions
of let-syntax and letrec-syntax that do that automatically.  Note
that (let () (let () ...)) is equivalent to (let () ...), so it
won't hurt anything if the native let-syntax and letrec-syntax
are introducing new local contours already.

So far as I can see, the R7RS (small) document does not require
let-syntax and letrec-syntax to introduce new local contours, so
any code that depends on that behavior is non-portable.  As you
have pointed out, five members of WG1 did vote to break backward
compatibility with the R6RS by requiring a new local contour, but
that decision does not appear to have found its way into the R7RS
document as ratified.

Because there do seem to be some programmers who believe the R7RS
requires let-syntax and letrec-syntax to introduce local contours,
I have added a new --r7strict mode to Larceny that disables several
of Larceny's extensions to R7RS, including that aspect of the R6RS
semantics for let-syntax and letrec-syntax.  I would encourage you
and others to write portable code instead of relying on such
implementation-specific modes and behaviors.

Will