Am Mi., 8. Okt. 2025 um 09:37 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> On 8 Oct 2025, at 04:39, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>
> > I know that you know this, but I want to repeat it here for the wider audience: SRFIs are requests for implementation, and do not impose any requirement on implementations.  In other words, the author of each SRFI is making a proposal, and is hoping that Scheme implementers and maintainers will take up the proposal.  Furthermore, according to the SRFI process we've been following since 1998, the editors (e.g. me, at the moment) must decide whether to accept and perhaps finalize each SRFI based only on whether it follows the required form, and not based on the editors' and reviewers' opinions of the proposed idea.  I've done my best to follow this process, which means, I'm afraid, that I can't "step in here and at the very least prevent this from happening."  But I'm sure that implementers will read SRFI 261 carefully and come to their own conclusions, and I can only imagine that your opinion will be important in their evaluations.
>
> I wish to submit SRFI 266. Although it is numbered 266, it in fact will define a new library called (srfi 1)/(srfi :1 lists). This library will be an alias for the R6RS lists library, which is much smaller than, and in a few cases incompatible with, Olin’s proposal. I think it would be better for Scheme if only the standard list library of the Scheme report were in common use.
>
> Do you see the problem here?

The tension stems from the fact that R7RS officially reserves the
"srfi" library name space (meaning "srfi" as the first component of a
library name) while no authority (e.g. the SRFI initiative) has set up
any formal rules about it. Thus, we only have SRFIs (97, and now 261)
that recommend how this namespace is to be used, but these are no more
than that, namely recommendations by their respective authors.

The obvious way out would be to agree on one library naming Scheme
(hopefully simple, brief, compatible with R6RS and R7RS, and taking
prior approaches into account) and making it an official part of the
SRFI process. Such an agreement could start as a SRFI that is then
officially adopted.

SRFI 0 is similar. It suggests feature flags of the form "srfi-NNN",
which can also be made official. (Having the same name, namely
"srfi-NNN", for both feature flags and library name components speaks
for the SRFI 261 convention versus the SRFI 97 convention, by the
way.)

An official ruling on the SRFI library namespace should also say
something about library version numbers (for systems that support
them) so that one can deal with PFN-induced corrections that may
slightly change/improve semantics) in a saner way. (My recommendation
here is just to use "(YYYY MM DD)" as the library version where the
date is given by the date of the PFN. Such a scheme works well with
how R6RS handles version numbers.)

Unfortunately, SRFI-0 feature identifiers may need versioning as well
for the same reasons, but there is no clear way how to add this to
what R7RS-small gives us. One may circumvent the problem by dropping
the idea of "srfi-NNN" feature identifiers and by testing for the
presence of (dummy) libraries in "cond-expand" (or whatever R7RS-large
will give us as a replacement) instead. If we go this route, which
looks promising, every SRFI needs an associated library name (even if
the corresponding library doesn't export anything).

Marc