I am extremely disappointed that this SRFI has been finalized without any of the issues raised during last call being addressed. I am especially disappointed to have received no reply from Arthur regarding my appeal to him on how this – now finalized – SRFI appears to retroactively invalidate the decisions of previous SRFI authors, myself included, before finalization. As it now stands there are two ways to interpret this SRFI: 1. That the library names ‘numeric-vectors’ for SRFI 4 and ‘bytestrings’ for SRFI 207 are no longer valid because a new SRFI has come along and declared them ineligible for names 2. That a second, parallel registry of SRFI library names has now been established, in which most of the names assigned by SRFI 97 and subsequently by SRFI authors are still valid, but some are absent or different, according to some arbitrary and unclear rules Both of these interpretations are absurd – and the SRFI should not have been allowed to reach finalization without resolving this problem. (Formal rationale: the SRFI process requirement ‘It must list related standards and SRFIs, including dependencies, conflicts, and replacements’ is not met, and there is an ‘inadequate design specification’ in that these conflicting interpretations are at all possible.) The former interpretation is extremely problematic because it goes against what seems to be the intuitive principle that a SRFI cannot be amended post hoc, least of all by a completely different author. Post hoc amendments by the same author have already caused nothing but trouble (SRFI 162/128); SRFI amendments by completely different authors not only invite chaos for programmers, but give no reason for SRFI authors to have faith that the specification they write will not be changed in unwanted ways by others in future. Separate, superseding SRFIs are the way to go, not rudely stomping the work of others out of existence. A completely new and distinct registry of SRFI library names would be a legitimate SRFI, in the sense that there is no formal requirement of the SRFI process that would forbid it. (There probably should be, perhaps in the form of a general ban on ‘meta-SRFIs’ in future, in favour of some other way of agreeing on reforms to the SRFI process.) However, given the scale of the overlap in library names with SRFI 97, it cannot be inferred from the spec as now finalized that this is the intention. Indeed, the sentence ‘Since SRFI 97, SRFI's family has been largely extended, and this proposal continues to include SRFIs with criterion the same as SRFI 97’ also strongly implies that it was *not* the intention here. A single sentence stating that a new registry of SRFI names is being established, rather than continuing the current one, would be entirely sufficient to clarify this – although ideally we would also get a rationale for *why* a new set of names is needed. As it is, this SRFI now stands to cause nothing but chaos and confusion for Schemers. I strongly advise implementers against adopting it. I would like to see it withdrawn without replacement, as the author has proven to be intransigent and incommunicative, and the existing process has not been respected. If withdrawal would be too much, at least it should be returned to draft status until I have lost a tremendous amount of faith in the SRFI process because of this. Daphne > On 8 Dec 2025, at 01:56, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote: > > Scheme Request for Implementation 261, > "Portable SRFI Library Reference", > by WANG Zheng, > has gone into final status. > The document and an archive of the discussion are available at https://srfi.schemers.org/srfi-261/. > Here's the abstract: > This SRFI proposal addresses systemic compatibility issues exposed by the SRFI 97-defined library reference format (srfi :<SRFI number> <identifier> ...) and advocates for two more modernized, portable and readable alternatives: (srfi srfi-<SRFI number>) and (srfi <identifier>-<SRFI number>). > Here is the commit summary since the most recent draft: > • Finalize. > Here are the diffs since the most recent draft: > https://github.com/scheme-requests-for-implementation/srfi-261/compare/draft-5..final > Many thanks to Zheng and to everyone who contributed to the discussion of this SRFI. > Regards, > SRFI Editor
