Marc Nieper-Wißkirchen wrote:

> As I said above, I wasn't aware of the incompatibility with the R6RS. In
> principle, coexisting could be possible because syntax-rules can behave
> differently when imported from different libraries, e.g. Larceny could
> make a difference between syntax-rules imported from (scheme base) or
> (srfi 149) or (rnrs syntax-case (6)).

That would create hard-to-find bugs when a program imports
syntax-rules from two different libraries, one of which
imports syntax-rules from (scheme base) and the other from
(rnrs base).

> (That said, SRFI 149 says that a system supporting it should export the
> same syntax-rules from (scheme base) and (srfi 149). But this still
> leaves room for (rnrs syntax-case (6)).)

None of this has anything to do with syntax-case or with
(rnrs syntax-case).  syntax-rules is exported by (rnrs base).

> > From Saunders MacLane, Categories for the Working Mathematician, page 13:
> >
> >     A functor is a morphism of categories.  In detail, for categories
> >     C and B a functor T: C -> B with domain C and codomain B consists
> >     of two suitably related functions: The object function T, which
> >     assigns to each object c of C an object Tc of B and the arrow
> >     function (also written T) which assigns to each arrow f: c -> c'
> >     of C an arrow Tf: Tc -> Tc' of B, in such a way that
> >
> >         T(1_c) = 1_{Tc},     T(g∘f) = Tg ∘ Tf,              (1)
> >
> >     the latter whenever the composite g∘f is defined in C.
> >
> > Before I even try to guess what you mean by "functoriality", I'd want
> > to know what the categories C and B are in your use of that word.

> My category C is the category whose objects are patterns P and whose
> morphisms are macro transformers f: P -> Q.

That is not a category, because macro transformers do not map patterns
to patterns.

> My functor T: C -> C is the
> endofunctor that maps a pattern P to the pattern (P ...) and that wants
> to map a macro transformer f: P -> Q to "the" macro transformer (f ...):
> (P ...) => (Q ...) that (intuitively) transform each instance of P in
> the list on the left into the corresponding instance of Q in the list on
> the right.

Because C, as you described it, is not a category, the T you described
is not a functor.

> SRFI 149's semantics has nothing to do with the relative positions of
> the pattern variables of different ranks. E.g. it would give the same
> result if the pattern was (foo2 (coordinate ...) ... (axis ...)). The
> way I read the R6RS, it either doesn't resolve the  ambiguity or it
> intends to specify that the input forms of the lower-ranked pattern
> variables are repeated if necessary.

All six of the R6RS systems I tested give the same result with that
alternative pattern, which casts doubt on the idea that R6RS systems
are agreeing on every example we try just by accident.

Will