I have already argued that the existence of SRFI 97 should not be taken as a precedent for future meta-SRFIs, and that a new procedure should be set up to avoid this kind of mess.

In particular, the historical context of SRFI 97 cannot be ignored – R6RS had just come out and there was arguably a need to clarify the relationship between it and the libraries defined in SRFIs – nor can the fact that the author of SRFI 97 was at the time a SRFI editor, lending it a kind of official status (beyond the idea that each individual SRFI represents only its own author’s opinion), which SRFI 261 cannot be said to have.

Furthermore, as I have said, I agree that the existing SRFI process does not actually *currently* prevent SRFIs which establish new library names – even if I think it should. I have argued that a SRFI clearly and explicitly establishing a new register of names would be conformant under the current rules. I don’t know how often I can repeat myself on these points. The problem is that this SRFI appears to re-assign existing names in an existing register.

To reiterate a question from an earlier post: How are you going to deal with the naming conflicts created by this SRFI in the SRFI metadata? There is a ‘library name’ field which you, as SRFI Editor, are responsible for maintaining. I sincerely hope you do not intend to give SRFI 247 the name ‘syntactic-monands’ nor SRFI 221 the name ‘generators&accumulators’.

I do not believe you are taking the problem here seriously, and I intend to ask the incoming steering committee to deal with this question.

Daphne

> On 9 Dec 2025, at 05:31, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>
> On Sun, Dec 7, 2025 at 9:44 PM Daphne Preston-Kendal <xxxxxx@nonceword.org> wrote:
>   There are numerous SRFIs I disagree with in how they go about solving the problem they attempt to solve. If I want to do better, I will submit a new SRFI which I think does the same job but better. I will not propose to have the other SRFI author’s proposal, in the form of the library they defined, changed. I will define a new library which represents *my* proposal. And I will certainly not try to declare that the name the SRFI author assigned to their own library is wrong and try to change or remove it.
>
> SRFI 97, published in 2008, proposed a naming convention for existing SRFIs.  It did that retroactively, and without specific consent of the authors of those SRFIs.  It was about a naming convention and a set of names, not about the APIs, syntax, etc. that those APIs themselves proposed.  Some implementations followed this convention, and some SRFI authors chose library names, but many did not.  A total of ninety SRFIs now have library names.  Many were given library names by SRFI 97, not the SRFIs' authors.  The library names were metadata, not part of the SRFI documents themselves.
>
> SRFI 261 proposes a revised naming convention, noting compatibility issues between the naming convention from SRFI 97 and naming restrictions imposed by filesystems and the URI standard.
>
> Naming conventions for SRFIs are a perfectly reasonable topic for a SRFI.  The editors working in 2008 obviously thought so, so I believed that they were still a reasonable topic, especially given the compatibility issues that Zheng reported in SRFI 261.  At least one other major SRFI contributor believes this, too.  If you read Zheng's Acknowledgments, you'll see that he credits Marc Nieper-Wißkirchen with the idea:
>
> I thank Marc Nieper-Wißkirchen for suggesting that I write this SRFI and providing a fairly complete context. I just wrote down his discussions.
>
> There's always room for debate, but everyone involved made reasonable efforts to follow the process, and no one "...rudely stomp[ed] the work of others out of existence."
>
> I invite everyone, but SRFI implementers in particular, to speak up in favor of or against either of these proposals, or to propose alternatives, or even to propose changes to the SRFI process.  Let's give each other the benefit of the doubt, and let's hear other voices, too.