Am Mi., 8. Okt. 2025 um 16:44 Uhr schrieb Daphne Preston-Kendal
<xxxxxx@nonceword.org>:
>
> On 8 Oct 2025, at 10:46, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
> > 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.
>
> I had thought that SRFI 97 was that SRFI, which had become an official part of the process by the recognition of its library names in the SRFI metadata.
>
> It is true that the process document contains no mention of it. But the Golden Rule must apply: the SRFI editor should take action to avoid a result that would be detrimental to generally-understood principles of reasonable public policy, even where no explicit written rule covering the specific case exists. That a SRFI author is not allowed to run roughshod over the clear intent of a previous SRFI’s author should be taken as such a principle. That the library names assigned by authors and recognized by the SRFI metadata are therefore somehow authoritative is a natural consequence.

If author A names their library "cond" and author B names their
library "conditionals" and both describe comparable extensions to the
"cond" syntax, it can make sense to later streamline the names either
both to "cond" or both to "conditionals", unless we give SRFI authors
full control over the sub-library name following the SRFI number. The
latter we can do, but this is not what SRFI 97/261 suggest.

> (The definition of ‘run roughshod’ is of course itself a vague matter doubtless needing debate over its specific application. But, say, SRFI 251 does not run roughshod over SRFI 245, although I thought it impolite that it was published without the idea being discussed in the SRFI 245 mailing list first. It would have run roughshod if it had said, for example, that the cond-expand srfi-245 feature symbol should be set by implementations supporting the SRFI 251 semantics.)

This would not happen in practice, would it?