Last call for comments on SRFI 261: Portable SRFI Library Reference Arthur A. Gleckler (07 Oct 2025 00:45 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Marc Nieper-Wißkirchen (07 Oct 2025 05:41 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Daphne Preston-Kendal (07 Oct 2025 05:45 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Marc Nieper-Wißkirchen (07 Oct 2025 06:10 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Daphne Preston-Kendal (07 Oct 2025 11:56 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Marc Nieper-Wißkirchen (07 Oct 2025 12:07 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Daphne Preston-Kendal (08 Oct 2025 07:37 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Marc Nieper-Wißkirchen (08 Oct 2025 08:46 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Daphne Preston-Kendal (08 Oct 2025 14:45 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Marc Nieper-Wißkirchen (08 Oct 2025 15:25 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Peter McGoron (08 Oct 2025 20:52 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Daphne Preston-Kendal (08 Oct 2025 21:26 UTC)
Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Daphne Preston-Kendal (08 Oct 2025 14:39 UTC)

Re: Last call for comments on SRFI 261: Portable SRFI Library Reference Peter McGoron 08 Oct 2025 20:52 UTC

On 10/8/25 10:44, Daphne Preston-Kendal wrote:
> 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.

I always thought that the SRFI metadata library names were a convenience
for users of implementations that follow SRFI-97. I have never
interpreted this as SRFI-97 being elevated in authority above the other
SRFIs.

I would probably strongly object to some SRFI being codified as the
authoritative organization of the SRFI namespace that no other SRFI can
displace, and definitely object to the codification of SRFI-97 or 261.

> 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.

The "generally-understood principles of reasonable public policy" should
not mean contradicting black-letter policy ("the editors may not reject
a proposal because [...] they think it is a wrong-headed approach to the
problem").

> 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.

A belief that a proposal is running "roughshod" over another proposal is
a special case of believing that the approach is wrongheaded.

> The definition of ‘run roughshod’ is of course itself a vague matter doubtless needing debate over its specific application.

This is an argument as to why the SRFI Editor should *not* reject SRFIs
for this reason. Implementers/users should decide, individually, which
SRFIs to support/use, and whether or not one "runs roughshod" over the
other will be a factor in that.

-- Peter McGoron