Marc Nieper-Wißkirchen wrote:
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.
As a side note: This could possibly be fixed in the Orange or any later edition of R7RS-large. Most users would expect that "(import (scheme comparator) (scheme hash-table))" would work without any problems (in particular, because the (scheme hash-table) strongly suggests to use it in conjunction with (scheme comparator)).
> (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.
In another implementation supporting both R6RS and R7RS this need not be, so portable code would have to take care.
Of course, requirements on compatibility with the R6RS could become part of R7RS-large. And the Larceny's existence proves that such requirements can be sensibly made.
> >> 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.
Which they are in my category C as explained in the more precise definition.
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.
Thanks.
> 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
At least when my interpretation of the R6RS is correct (and the different implementations seem to agree).
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).
The reason why the author (at that time ignorant about any requirements by the R6RS) added this sentence was to free programs from writing
(import (except (scheme base) syntax-rules)
(srfi 149))
instead of the simpler (import (scheme base)). The existence of (srfi 149) as a library was supposed to be used just for feature detection using cond-expand.
I will have to talk to the SRFI editor whether we could add a post-finalization note that leaves it to the implementor whether this extra requirement is adhered to or ignored and that suggests a feature identifier, say "srfi-149" instead, that is flagged when (scheme base) exports a SRFI 149 compatible version of syntax-rules.
> 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.
A hypothetical semantics that makes it possible to write the macros foo2 and gen-extract* cannot be completely compatible to the semantics of the R6RS (or to the semantics of this SRFI).
Given that such a hypothetical semantics is superior, WG2 may adopt it for inclusion into R7RS-large. With respect to compatibility to the R6RS, this will be no more different than SRFI 149 vs. R6RS. So, what I want to say is that while the language evolves, introducing incompatibilities may be accepted because some earlier choice was a suboptimal one (I don't want to necessarily imply that SRFI 149 made a choice that much better than the R6RS so that it would warrant such an incompatibility).
A much more subtle change than the things we have been discussing was the semantic change for internal definitions from the R5RS to the R6RS. In the R5RS, they obey letrec-semantics, from the R6RS on they obey letrec*-semantics.
--
Marc