If we want to be able express the (non-splicing) let(rec) in terns of let(rec)-splicing by using the simple transformation
(let(rec)-syntax <bindings> <body>) => (let () (let(rec)-syntax/splicing <bindings> <body>),
the snippet from above will have to evaluate to bar.
Now, consider the following example:
(let ()
(let-syntax/splicing ()
(define let-syntax/splicing #f)
#f))
This must be possible if we want this snippet to behave as a non-splicing let-syntax. It would, however, be violation of 5.4 of the R7RS, where is says:
"Macros can expand into definitions in any context that
permits them. However, it is an error for a definition to
define an identifier whose binding has to be known in order
to determine the meaning of the definition itself, or of
any preceding definition that belongs to the same group
of internal definitions. Similarly, it is an error for an internal
definition to define an identifier whose binding has
to be known in order to determine the boundary between
the internal definitions and the expressions of the body it
belongs to."
So I would like to see clear semantics for let(rec)-syntax/splicing that is in accordance with the rest of the R7RS. Possibly, let(rec)-syntax (non-splicing) won't be implementable with let(rec)-syntax/splicing then, meaning that we actually have too different binding constructs neither of which is expressible in terms of the other.
--
Marc