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