To wrap up the discussion, the next draft (already submitted to
Arthur) will contain a reference to sc-macro-transformers but also,
and much more importantly, (hopefully) a solution to two problems,
namely that the provided primitives for er-macro-transformer are not
enough to write macros people want to write and that a satisfying
coexistence of er-macro-transformers and syntax-case still has to be
found.

The solution is the low-level macro facility documented in the
appendix to the R4RS, almost thirty years ago. This abstracts a bit
more than er-macro-transformer, making it compatible with both
systems, and has otherwise the primitives that are missing in the
(srfi 211 er-macro-transformer) sublibrary.

More in the upcoming new draft.

Am Do., 24. Sept. 2020 um 10:25 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:
>
> Am Mi., 23. Sept. 2020 um 19:50 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> > On Tue, Sep 22, 2020 at 7:34 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
> >
> >> I would like to hear some opinions on the following questions:
> >>
> >> (1) Shall we include another library for sc-macro-transformer?
> >
> >
> > I'm fine either way.  For standardization purposes, syntactic closures are rare enough (MIT, Chibi, Picrin) that I don't plan to put them on an R7RS-large ballot, which will leave people with yes/no/abstain ballot entries for syntax-case and explicit renaming.  A straw ballot years ago voted for explicit renaming but not syntax-case, but I don't consider that binding.
>
> This SRFI is not only for standardization purposes but also to make
> macro systems usable in a portable way by providing a namespace where
> they can be advertised.
>
> As for the R7RS-large ballot, formulating it may be the hardest task
> so that depending on the outcomes we don't end up with a system that
> is hard or impossible to implement efficiently and consistently.
> Moreover, we have to agree first what the semantics of
> `er-macro-transformer' actually is. For example, Larceny's
> `er-transformer' is incompatible to Chibi's `er-macro-transformer'.
>
> 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.
>
> >> This would include the following exports:
> >>
> >> - sc-macro-transformer
> >> - rsc-macro-transformer
> >> - make-syntactic-closure
> >> - capture-syntactic-environment
> >
> >
> > MIT Scheme (see the subpages of <https://www.gnu.org/software/mit-scheme/documentation/stable/mit-scheme-ref/Syntactic-Closures.html>) provides the convenience procedure (close-syntax form env) === (make-syntactic-closure env '() form).  For compatibility with existing macros, this should be provided.  The MIT documentation also says that (make-syntactic-closure env '() 'a) provides an alias, though no convenience version is provided.  Picrin also provides close-syntax; Chibi does not, but it would be trivial to add.
>
> I wanted to add close-syntax but somehow this got lost. Thanks for the catch.
>
> >>
> >> - identifier?
> >> - identifier=?
> >> - make-synthetic-identifier
> >>
> >> * Both sc-macro-transformer and er-macro-transformer are lacking an
> >> equivalent of syntax->datum to get at the symbol names of identifiers.
> >
> >
> > Chibi, but not MIT or Picrin, provides identifier->symbol and strip-syntactic-closures.
>
> So if we add it, we don't know whether it will be supported by more
> than one Scheme.
>
> >> * Syntactic closures created by sc-macro-transformer cannot be destructured.
> >
> >
> > I think that's why they are called "closures".
>
> I have been thinking that the term "closure" refers to the sense of a
> "closure" of a function in functional programming tracing back to the
> original LISP's FUNARG.
>
> I cannot believe that the non-destructability is meant as a feature
> because it makes it impossible for a macro to expand into another
> macro written in that language.
>
> >> We can leave it at that, but this would mean that applicability and
> >> expressiveness of sc-macro-transformer and er-macro-transformer will
> >> be rather limited compared to the syntax-case system.
> >
> >
> > In my view the point of having them is so that (a) existing macros can be reused, and (b) users of these systems who are accustomed to them can continue to write them.  Expressive power beyond what people already expect is more or less irrelevant.
>
> I don't think it is entirely irrelevant. With the bare
> er-macro-transformers, SRFI 99, Clinger's ERR5RS records, for example,
> cannot be implemented, yet people have been attempting to do so, which
> leads to macros that work in 99% of the cases, but not in 100%. If we
> give programmers a tool, especially programmers who are not interested
> in "esoteric" corners of the language, the tool should be as
> fool-proof as possible.
>
> That's why I would like to see a version of er-macro-transformer (if
> any) that produces correct code without much thinking.
>
> The problem with the minimal interface currently provided by (srfi 211
> er-macro-transformer) is that one can only safely write hygienic
> macros.
>
> >> Or we could add a number of further primitives.
> >
> >
> > As far as I know, no other Scheme implements anything but these.
>
> Larceny's `er-transformer' has `bound-identifier=?' and
> `datum<->syntax', for example.
>
> Marc