+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.

On 9/28/20 3:29 AM, Marc Nieper-Wißkirchen wrote:
> Hi Vladimir,
>
> thank you for your input!
>
> Am Mo., 28. Sept. 2020 um 03:57 Uhr schrieb Vladimir Nikishkin
> <xxxxxx@gmail.com>:
>> Hello,
>> Thank you for your job!
>>
>> I just had a few questions about this srfi.
>>
>> 1)If its main aim is to define standard library names, would it not be
>> worth including (srfi 211 defmacro) for legacy macros, and (srfi 211
>> syntax-rules) for the r7rs macros?
> We already have (scheme base), which exports syntax-rules, so I don't
> see the need for a library alias just for syntax-rules. (Strictly
> speaking, this is also true for (srfi 211 syntax-parameter), for which
> we already have (srfi 139), but the latter is not a standard R7RS
> (small) library.)
>
> I can add a defmacro library for those Schemes that do not provide any
> of the other libraries. Does Guile
> (https://www.gnu.org/software/guile/manual/html_node/Defmacros.html)
> document an established standard for defmacro in the Scheme world?
>
>> The first could provide a helpful error message urging users to update
>> their code on systems that do not want to support defmacro, and the
>> second one would be a no-op on r7rs systems, and would actually
>> provide syntax-rules on the non-r7rs systems.
> Which systems do have R7RS libraries but not syntax-rules? Already R5RS had it.
>
>> 2)There are no procedures or syntax doing any sort of macro expansion.
>> Almost all implementations, however, do provide some form of
>> macroexpand, macroexpand-1, macroxpand:eval.
>> SLIB lists those for almost every macro system:
>> https://people.csail.mit.edu/jaffer/slib/Scheme-Syntax-Extension-Packages.html#Scheme-Syntax-Extension-Packages
>> Are they clearly out of scope for this SRFI?
> Is there clear semantics of these procedures? In general, full macro
> expansion does not produce some s-expression but some internal ast
> (which may be represented by an s-expression, of course).
>
> Thanks!
>
> Marc