Am Fr., 31. Juli 2020 um 10:49 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> - How often would a new registry SRFI be published, and where would new
> submissions be gathered in the meantime?

There could always be one SRFI in draft status, which accepts new
registry entries in the meantime.

The noise will then mainly happen on the mailing list of that SRFI.

> - Scheme implementations typically claim that they support particular
> SRFI numbers. What (if anything) should they say about which registry
> SRFIs they support? It they list all of them, it would cause a lot of
> new identifiers in (features) and (cond-expand) over the years. Perhaps
> such registry SRFIs should simply be omitted from the (features) list.

SRFIs do not need entries in the features list. As long as they define
a library with its name, a cond-expand with this library name is
enough to check for its existence.

By the way, the claim that a scheme implementation supports that many
SRFIs doesn't say much about the quality of the support, in particular
when just the generic sample implementations have been copied.
Moreover, more SRFIs doesn't necessarily make an implementation a
better system. So in many cases, one should shrug this off as
advertising.

(Look at Guile's non-existing built-in support of SRFI 121 to get a
different view on the topic:
https://lists.gnu.org/archive/html/guile-devel/2019-07/msg00000.html.
Mark's arguments are sound, but they mean that an implementation may
be better with fewer SRFIs. SRFI 121's generators have been wired into
many other SRFIs lately because it has been claimed that they are much
faster than, say, SRFI 41 streams. Apparently, they are not. And
without a proof that SRFI 41's streams cannot be made nearly as
efficient as generators, it would have befitted Scheme as a functional
language to replace generators by streams. Haskell shows that
efficient implementations of streams are possible. But that's a
different area needing improvement.)

Marc