Am Mi., 30. Sept. 2020 um 02:45 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
>
> On Tue, Sep 29, 2020 at 3:46 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>>
>> Am Mo., 28. Sept. 2020 um 20:37 Uhr schrieb Adam Nelson <xxxxxx@nels.onl>:
>> >
>> > +1 for defmacro (more often spelled define-macro in Scheme), because a
>> > lot of Schemes only have that, and my experience in Schemepunk has been
>> > that I sometimes have to drop into defmacro to write portable code for a
>> > few Schemes that have broken syntax-rules/syntax-case implementations.
>>
>> Consider it added, then.
>
>
> Please, please no.  defmacro doesn't compose with any other macro
> system (except to some extent ER).  Mixing it is pretty much guaranteed
> to break.

I am certainly the last one who will advocate the use of define-macro
except for demonstration purposes and for teaching (why hygiene is
important). But I think that Adam and Vladimir are right in that it
fits the original scope of this SRFI, namely to be able to write
maximally portable code, for which it may be better to use a fall-back
solution like define-macro instead of providing no solution
whatsoever.

Note that implementations who want to support this SRFI are not forced
to include support for (srfi 211 define-macro). Although I added it to
Unsyntax for completeness and to demonstrate all macro systems of SRFI
211 on one underlying implementation, I may even encourage
implementations not to include (srfi 211 define-macro) if they have a
working syntax-case or er-macro-transformer implementation.

Before the final draft is out, I will also add a big fat warning about
the issues of define-macro. Nevertheless, it is being used for some
poor man's solutions, like the implementation of SRFI 190 in STklos.

What do you mean by "it doesn't compose with any other macro system
(except to some extent ER)"? I agree that it doesn't compose smoothly,
but "to some extent" it can compose with any other macro system. It
will break in at least three situations: When some expected bindings
at the use site do not exist (but this has always been a problem of
define-macro) or when it is used with some other macro that absolutely
relies on hygienic renaming for it to work.

But traditional ER macros like the classical loop macro also break in
similar situations (they do not compose well and don't work when used
in the output of another macro. Nevertheless, in many Schemes, we
currently have no better system, so the situation is, at least,
somewhat comparable.