Marc Nieper-Wißkirchen wrote:

> Furthermore, do we expect many programs to import (scheme base) and
> (rnrs base) the same library?

Yes.

Larceny's code base contains many libraries that import both of
those libraries.  I went to a great deal of trouble to make it
easy for Larceny users to import from R6RS libraries as well as
from R7RS libraries.  Larceny's -r7r6 command line imports all
standard libraries of both R6RS and R7RS Red Edition, with only
two name conflicts that required renaming (bytevector-copy! and
remove) and two name conflicts that required the deprecated
string-hash and string-ci-hash of (scheme hash-table) to be left
out of the (larceny r7r6) library altogether.

Please note that the deprecated string-hash and string-ci-hash
of (scheme hash-table) were known to be incompatible with the
string-hash and string-ci-hash of (scheme comparator) when WG2
decided to make both of those libraries part of R7RS Red Edition.
In other words, that name conflict was mandated by WG2.

> (This issue is not a particular new one, I think. A program combining
> R7RS-large and R6RS fragments will likewise have to cope with the fact
> that, say, string-hash from (scheme comparator) may not be the same
> procedure as string-hash from (rnrs hashtable (6)).)

In Larceny, those two libraries export the same string-hash.

> >> 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.
> (A morphism in a general category doesn't need to be a map at all.)

No, but the domain and codomain of each morphism must both be
objects of the category.

> > 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.
> How many different macro expanders do these systems use at their heart?

At least three, and probably five or more.  The three I know
about for sure are the Racket expander (used only in Racket),
Andre van Tonder's expander (Larceny), and psyntax (Vicare,
Chez, and Petite Chez).  I believe at least two other R6RS
systems rolled their own as well.

> Regardless of the number of implementations, what R6RS most likely
> specifies (unfortunately, the text is rather terse, and SRFI 93 doesn't
> explain it better) is what I wrote in the previous post and which
> amounts to the fact that in case of extra ellipses in the template, the
> outermost ellipses replicate, while the inner ellipses iterate. SRFI
> 149, on the other hand, requires that the innermost ellipses replicate
> and that the outermost ellipses iterate.

So SRFI 149 is fundamentally incompatible with the R6RS.  That
alone would not prevent Larceny from supporting SRFI 149, because
Larceny supports several SRFIs whose exports conflict with standard
R7RS or R6RS libraries, but SRFI 149 says "The only export of
(srfi 149) shall be syntax-rules with the same binding as syntax-rules
from (scheme base)."  That sentence, notably the word "shall", makes
it necessary for Larceny to choose between SRFI 149 and consistency
between (scheme base) and (rnrs base).

That's an easy choice, because interoperability between R6RS and
R7RS code is a primary goal of Larceny.  Larceny will not support
SRFI 149.

> So, ignoring consistency between the various standards for the moment,
> the main question that remains is whether SRFI 149's semantics is more
> useful/is more intuitive/has more applications than R6RS's semantics, or
> whether their is a superior semantics to both, making foo2 and
> gen-extract* both possible at the same time.

I believe it should be possible to describe a semantics that would
be superior to both.  If that is done by a subsequent SRFI, I hope
its author(s) do not insert language that make it impossible to
support the SRFI without breaking backward compatibility.

Will