[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] 5.3 Syntax Definitions
On Fri, 3 Jun 2011, Jim Rees wrote:
> R6RS *tried* to cover this, but it was difficult to interpret, especially in
> the context of the detailed expansion semantics:
> "A definition in the sequence of forms must not define any identifier whose
> binding is used to determine the meaning of the undeferred portions of the
> definition or any definition that precedes it in the sequence of forms."
> But it did not go into detail about what constitutes "meaning".
A better wording might have been:
An internal definition or syntax definition must not define any identifier
whose binding or lack of binding in surrounding code has already affected the
expansion of preceding portions of the body, up to and including any undeferred the
portions of the definition or syntax definition itself.
Something like this is important to prevent anomalous lexical scoping, where two
identifiers in the same body scope refer not to the same binding but to two
different bindings, which should be impossible. We have to include not inly
preceding parts of the body but also the definition itself to prevent things like:
(define-syntax ... (syntax-rules () ((_ arg ...) (list arg ...))))
(... 1 2 3))
This should give an error, NOT (1 2 3), because inside the body ... can only
mean the local binding, not the macro ellipsis. Otherwise, ... would have two
meaning in the same lexical scope, which would be a scoping anomaly.
> I don't want to have an R6RS conversation, only to request that the WG be
> better than R6RS was about the wording it uses. What does it mean to "use
> a syntax definition" and what does "before" mean? Must everything be
> expanded in left-to-right order - and if so, how does one handle the
> even?/odd? example? Can there be a reference to an identifier in the
> template part of syntax-rules that resolves to a definition that comes
This is not a problem, even if we expand in left to right order, i.e.,
(define-syntax even (syntax-rules .........odd.....)
(define-syntax odd (syntax-rules .........even...)))
presents no problems, since the definition of the ODD macro is not necessary for
expansion of the preceding code.
Scheme-reports mailing list