Hi Alex,

> Apologies, your replies are very long and I've only had time to
> skim them, which is inconsiderate.  I'll have to bow out of this
> discussion (and all SRFI discussions) for a while now for personal
> reasons.

No problem. There are many more things more important than this
academic discussion. In particular, as we probably agree more than
that we disagree.

I hope your new job is going well. (May you want to tell me
(privately) where you are working now?)

> What I can say is the intent of the standard was not to allow
> arbitrary macro expansions into quoted cyclic data.  In fact,
> that is not a specification at all because it just translates to
> "implementation defined."  One can implement a quasiquote
> which supports cycles, but most don't.
>
> Quasiquote is somewhat special in that it is inherently a
> code-walking macro, something which should be discouraged
> but does come in handy on occasion.  Other examples include
> test/assert macros which report interesting variables referenced
> in their body, and variants of cut/chain which allow nesting
> <>/_ deeper in the body than just top-level.  The macro
> system itself and/or pattern matcher may want some limited
> walk ahead for diagnostics and/or optimization.  All of these
> run afoul of cycles.   In fact this is true whether they are
> quoted or otherwise, but a quote guarantees at least one
> extra safety depth and is easier to check against.

I agree with you that the macro expander cannot handle cyclic data and
that cyclic data and that the attempt to expand cyclic datums would be
an error. I think we also agree that at least after expansion, the
only place where cyclic datums are allowed are in expression of type
literal.

To make arbitrary code-walking by macros feasible, I think we also
agree that syntax-rules is not enough. The macro expander works
strictly top-to-bottom. For code-walking to be possible in all cases a
way to enforce expansion of a macro argument would be needed. While
cycles are the most obvious problem for code-walking macros, there are
a lot more (unknown macros in the body, unhygienic macros, include,
...).

> So you would either need to address this, or leave it all
> implementation defined.  What that means is it will work in
> some but not all implementations, which is actually the same
> specification as "is an error," so perhaps we've been arguing
> the same thing the whole time :)

I guess so. :) Every full implementation you would write or I would
write would probably report exactly the same programs as erroneous
(which includes a non-terminating macro expansion).

Moreover, if we just dropped the explicit restriction statement in
2.4, I guess nothing would change for both of us. No more programs
would be legal than that are now. In all cases that 2.4 forbids, the
expander would loop anyway.

Marc