Am Mi., 6. Jan. 2021 um 02:53 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Wed, Nov 25, 2020 at 2:47 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>>
>> While I managed to put all of SRFI 211's macro systems in one expander, I don't think that having multiple systems in a standard makes a lot of sense. It would make sense if different problems needed different macro systems to solve. But as far as the existing systems are concerned, it seems there is no sensible macro that you cannot write with syntax-case but with one of the other systems (or a macro where using one of the alternative systems would lead to simpler code).
>
>
> I agree.  But in the end, the acceptance of an RnRS is driven by implementers and users.  Adding and using novel macro syntax is a substantial investment for both groups  Fortunately, implicit renaming and/or syntactic closures are supported only by three systems (Chibi, MIT, Picrin, all of which support either syntax-case or ER, so they can be dismissed as R7RS standardization targets.  (Note: I am ignoring Unsyntax here.)

That cannot certainly be the only measure. Otherwise, we would be
standardizing C.

> syntax-case only: Racket, Gambit, Guile, Kawa, SISC, Chez, Vicare, Loko, Ypsilon, Mosh, IronScheme, SXM
>
> Explicit renaming only: Gauche, MIT, Chicken, Scheme48/scsh
>
> Both: Chibi, Larceny, Picrin, Sagittarius
>
> Neither (but does have syntax-rules):  Bigloo
>
> That looks like it's overwhelmingly pro-syntax-case, but IMO the R6RS systems should only count as one, since R6RS support mandates syntax-case.  That leaves us with syntax-case 6, ER 4.   But if we eliminate Schemes rarely used and/or not in development, we end up with Racket-and-Chez, Gambit, Guile, Kawa on the one hand, and Gauche, MIT, Chicken on the other.

While just counting the numbers of implementations is not a good
measure, counting all R6RS systems as one doesn't seem any better.

Before counting any numbers, we should take a look at the merits of
each system. And for syntax-case, I do see the following:

- Leads to readable macro code.
- Offers procedural macros.
- Can implement robust unhygienic macros.
- Not hard to implement.
- Has some pedagogical pros.
- Is already part of a prior standard.

On the other hand, with explicit renaming macros I only see the following:

- Offers procedural macros.
- Not hard to implement.
- Has other pedagogical pros.

>> Consider the following fragment of a library body:
>
>
> I rewrote your incomplete code as the simplest thing that could possibly work:
>
> (define-library (phase)
>   (export foo bar quux)
>   (import (scheme base) (chibi syntax-case))
>   (begin
>     (define (foo) bar)
>     (define-syntax quux
>       (lambda (x) (foo)))
>     (define (bar) (quux))))
> I changed "quux" to "(quux)" because Chibi does not support identifier syntax.  Everything comes out fine: (foo) => #<procedure bar>, (quux) => void, (bar) => void.  In an R6RS version, Guile reports that foo is undefined, as you say.  In a native Chicken version using ER, ditto.  In the REPLs, however, it's bar that is undefined, because bar attempts to invoke itself as part of its definition.

Chibi tries to use the same semantics for the REPL as for library and
program top-level. This is mostly fine but there seem to be some
problems with this approach as when top-level macros are involved so
that the top-level program or library semantics cannot be captured
completely. (See the discussion here:
https://github.com/ashinn/chibi-scheme/issues/399).