Am Fr., 25. Sept. 2020 um 19:01 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

[...]

>> > I don't consider Larceny to have an implementation of ER macros (or Racket either), though I did list Larceny under ER systems faute de mieux.
>>
>> I wouldn't abandon Larceny's implementation so easily. It is a sane
>> implementation.
>
>
> I don't want to reject it, just to distinguish it.  The fact is, we have eight Schemes with implementations of ER, and there may very well be that many implementation strategies.  Here's what I know or guess:
>
> Gauche, Scheme48: Native implementations
>
> Chicken, Picrin: Native implementations (they also have IR in parallel)
>
> Chibi: On top of syntactic closures.
>
> MIT: Probably on top of syntactic closures.
>
> Sagittarius: Also has syntax-case, but I don't know the relationship.
>
> Larceny: SRFI 72.

I am not sure whether the term "native implementation" is
well-defined. The only thing one can state with certainty that the
above systems have some core in common.

[...]

>> Another difference is that the other ER systems allow raw
>> symbols in the output, but the semantics of that is questionable
>> anyway and should be left as an error in a possible standardization.
>
>
> We should warn that that limits portability, but not outlaw it.

Saying that "it is an error" seems to be effectively the same.

In any case, with the current ER systems, outputting raw symbols is
broken anyway.

In Unsyntax, I made the change of closing raw symbols in the use
environment, which is the only sane way to handle them.

>> >> In any case, I hope that we will be able to reach a consensus before
>> >> any voting because the results of such votings are often erratic.
>
>
> General rant (which is why I have cc'ed scheme-reports-wg2):
>
> Reason is not the deciding factor in this process, and is less important than consensus (if we can get it) or a vote (if we cannot).  Both of these are erratic processes: it is easy to reach a consensus on something that is, sub specie aeternitatis, a mistake.  We have done it many times.  One reason for having open voting in WG2 is that it allows the source of decisions to be more broad-based and inclusive.
>
> Rather, reason is a rhetorical technique for getting people to vote for what you want.  It is a (morally) good technique, and we encourage people to use it rather than the (very effective) techniques for "making the worse cause appear the better.  But in the end, that's all it is.  Decisions come from committee votes (and people rarely or never explain their votes), and ultimately from implementers and programmers.

Maybe I can follow you here, maybe not.

I will answer with an example. Consider the question of whether "1 is
a prime number". Even though it is a question about how to define a
concept, there is only one legitimate sane answer. Although I may use
reasoning to explain the correct answer, the truth of the answer is
independent of any reasoning, let alone of any voting.

Not all questions are like this one, of course.

>> > I think that is very unlikely.  Nobody is likely to come up with an unshakable explanation for how one can be rooted in the other; many have tried, and some have gone on record that they don't think it can be done.
>>
>> See the R4RS system I added to the SRFI, which can serve as a common
>> denominator.
>
>
> Very nice!
>
> I think asking people to read a paper or (mutable) implementation documentation is inadequate for something that itself is part of the permanent record and and may become (as a whole or in part) an element of R7RS-large.  I think therefore that the exports of (srfi 211 er-macro-transformer), (srfi 211 ir-macro-transformer), (srfi 211 with-ellipsis), and (srfi 211 sc-macro-transformer) should be fully documented here, most of which can be done by cut and paste.  This is particularly important if you are going to change the exports or the semantics.

The licenses for the things that are to be copied and pasted have to
be checked. The documentation at least for sc-macro-transformer and
with-ellipsis comes from GNU projects that archive earlier versions,
so when we fix the version, mutability matters less.

That said, I can fill in specifications but these will probably (have
to) make choices, which I am currently evading (especially in the case
of ER macros).

> In addition, since Racket has a greatly expanded syntax-case system, the library name should be r6rs to indicate what version of syntax-case the SRFI conforms to.  I also think it is clearer and easier if you use explicit-renaming, implicit-renaming, and syntactic-closures in the library names.  People who use these facilities know they are macro transformers, so let's emphasize the difference rather than the similarity.

I would rather want to find a substitute for the (srfi 211 r4rs)
library name, which I just chose for the lack of a better name. Maybe,
(srfi 211 low-level) is already a better name. I won't rename (srfi
211 syntax-case) to (srfi 211 r6rs) for another reason: The R6RS macro
procedures/syntax are split into several sublibraries here because
identifier syntax or variable transformers are completely orthogonal
to syntax-case and apply (when present) equally well to all the other
macro systems.

The change of the XX-macro-transformer library names to something more
specific sounds reasonable.

>> Of course, to reach consensus, implementers must be willing to do some
>> work on their implementations.
>
>
> Naturally, but how much, and what existing code will it break?  It's one thing to ask ER implementers to add bound-identifier=?, another to disallow raw symbols in the output.

As I wrote above, macro transformers that output raw symbols are, in
currently existing systems, in general, broken anyway. Anyway, making
it an error to output raw symbols in a standard doesn't mean that each
individual system has to forbid them. We are not producing R6RS
mustard. :)

That said, I would advise not to ban raw symbols if the underlying
macro system ensures that the resulting symbols are closed in the use
environment, which is what you want anyway when you produce symbols.

As for how much work: Initially, Unsyntax only had syntax-case. Now
(after hacking 2 days) it supports all the systems described here.

> Another general rant:
>
> It is important when designing a SRFI for which there is a lot of semi-compatible prior art to try to leverage that art as much as possible.  When writing SRFI 143 (fixnums), I designed the SRFI to be as system-independent as possible, but when the implementation is running on Chicken, it exploits (chicken fixnum), which the compiler knows how to optimize.  There is a portable implementation, rubber-chicken.scm, of the parts of (chicken fixnum) that are needed to use it on another Scheme, so the sample implementation as a whole remains portable.
>
> Of course this is only an exemplar.  If some other Scheme has a different set of fixnum primitives, it can and should adapt the sample implementation to use its own as the basis.  In particular, the Chibi version simply uses the generic operators, as Alex said they are no slower than specialized ones would be, and since overflow is an error, that's not a concern.

I am slightly at a loss here. Aren't we doing exactly this by trying
to find some common denominator?

PS: The current "pre-next-draft" version of SRFI 211 is here:
https://htmlpreview.github.io/?https://github.com/mnieper/srfi-211/blob/master/srfi-211.html.
I had already added a number of comments to ER macros before I
received your email.