On Fri, Sep 25, 2020 at 2:35 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
Am Do., 24. Sept. 2020 um 23:58 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:

> This is an extremely confusingly named SRFI, which
> points at its unusual nature.

I am very open to a better name and would love to hear suggestions.

Either "Macro Systems" or "Macro System Libraries" would be better.
"Namespaces" has a specific technical meaning actually provided by some Schemes.
 
> The usual thing would be to simply have a SRFI for
> ER macros, and a separate SRFI for syntax-case, etc.
> I suggest we do that.

We would end up with roughly 7 SRFIs, each of which would more or less
just consist of a list of identifiers.

That in itself is a problem.  Pointing to the various manuals at
the time the SRFI was written is not a sufficient specification.
Those documents are ephemeral, and may change or no
longer have the relevant information in the future.

SRFI 97 is different because it points to other SRFIs, which are
not only clear specifications but specifications within the same
framework.  So long as SRFI 97 is available we can assume they
are as well.

The purpose of this SRFI is not to document each of the macro
subsystems extensively (which is already done elsewhere)

No it's not.  There is no specification of SC, and the manual
leaves much to be desired (I implemented an SC variant, but
don't really understand it myself). The purpose of a SRFI
should be to state the exact semantics so that 1. during
discussion we can find corner cases and differences in impls,
and 2. afterwards implement it from scratch from the SRFI
document alone.

There is also no specification of ER (or IR) macros, though
Clinger's paper is clearer and they are simple enough people
tend to end up with the same thing.  However it doesn't mention
the `syntax-quote' provided by Chibi without which it's nearly
impossible to write syntax-defining macros (like syntax-rules).

`with-ellipsis' looks trivial enough that the Guile manual almost
constitutes a specification, but that full text belongs in the SRFI.
But this seems like a pretty random macro utility to single out
in this SRFI.

Since we already have SRFI 93, I would suggest just starting
with a new SRFI for ER macros with an actual specification.
Programmers can cond-expand on the two.  SC is rare enough
that I wouldn't bother in portable code, but if someone is
really motivated they can create an SC SRFI.

--
Alex