On Fri, Jan 4, 2013 at 12:03 PM, Daniel Villeneuve <[email protected]>wrote:
> Without syntax definitions, a sequence of definitions is
> equivalent to a letrec* form (Section 5.3.2).
>
> With syntax definitions, since this is explicitly not covered by Section
> 5.3.2,
> the wording of Section 5.4 should be used. However, it is not said:
> - what happens with too mutually recursive syntactic definitions;
> - how to split subsequences of regular and syntactic definitions.
>
Mutually recursive syntactic definitions work as they always
have. I'll see if I can clarify the language, but basically this
works just like the top-level - the variables and syntax all refer
to each other. Redefinitions are forbidden, and obviously
actually using a value before it is lexically occurs is an error.
There's no need or desire to split syntax and non-syntax.
I would propose the following rewrite:
>
> Given a sequence of definitions and syntax definitions at the start of
> a <body>, let r_i be the identifier bound by the i^{th} definition v_i
> and s_i be the identifier bound by the i^{th} syntax definition d_i.
> Then, the entire sequence of definitions and syntax definitions
> is equivalent to
>
> (letrec-syntax ((s_i d_i) ...)
> (letrec* ((r_i v_i) ...)
> <expressions>+))
>
> Is this a plausible rewrite?
>
Unfortunately this rewrite wouldn't work - it's important that the
syntax definitions refer to the non-syntax definitions, thus they
must all be in the same lexical contour.
> I know it conflicts with the wording at the end of Section 5.4 which says
>
> > Any use of a syntax keyword before its corresponding definition is
> > an error.
>
> but if the above rewrite is "correct", this error condition could be
> dropped.
>
Note this is not necessarily conflicting - it is still an error
to _use_ a syntax before its corresponding definition,
even in letrec-syntax. It is not an error to write a macro
which expands into a reference to some syntax, so
long as that macro is never expanded before the syntax
is defined.
--
Alex
_______________________________________________
Scheme-reports mailing list
[email protected]
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
