Am Mi., 23. Nov. 2022 um 12:36 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
>
> On Tue, Nov 22, 2022 at 9:05 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>>
>>
>> This is much better than an explosion of SRFI numbers.
>>
>> Consider, for example, SRFI 158.  Its make-coroutine-generator is
>> written with call/cc, which can cause a space leak.  With SRFI 226 at
>> hand, a better version (and a version compatible with continuation
>> barriers) of make-coroutine-generator is written with delimited
>> continuations.  Now, in those cases where it matters, a consumer
>> importing SRFI 158 should be able to make sure that the modern version
>> make-coroutine-generator is imported.  We could create SRFI 258 (SRFI
>> 158 with an amended description of make-coroutine-generator), but it
>> would be much better to just add a PFN to SRFI 158 and assign some
>> version number to it so that (import (srfi 158))) would just import
>> any version, (import (srfi 158 (1 0 0))) would import the original
>> version and (import (srfi (1 1 0))), say, would import a version
>> respecting the PFN.
>
>
> I'd rather think of SRFIs to libraries as RFCs to protocols.  There are a great number of RFCs, many of them add or amends preceding RFCs, but most users don't refer to each individual RFCs by numbers. For time to time, an RFC is provided to define a specific protocol of certain version number (e.g. HTTP/3) that serves as an anchor of other detailed RFCs.
>
> Suppose we have (srfi list) library.  I avoid using (scheme list) to show this is a hypothetical argument.  (srfi list (1)) is defined as the same as (srfi 1).   Eventually we learned from experience that we want to add more procedures, or extend existing ones and a bunch of small srfis are discussed and finalized.  Eventually, a new srfi (srfi 1001) is submitted, which gathers list-related srfis that have been proven to be useful, and declares the new set of APIs to become (srfi list (2)).
>
> From the user's point of view, one can always use (srfi list) for basic (srfi 1) features, and new code use (srfi list (2)) to get all new features, without remembering and importing all those small srfis.

SRFI 97 is close to this.

There is (srfi :1 lists) but this does not preclude a (srfi :1001 lists).

This works because it provides versioning; the only problem I see here
(but maybe it is no problem) is the proliferation of SRFIs.  For
example, the erratum to SRFI 124 would have needed an almost verbatim
copy of that SRFI, say as SRFI 1124, so that programs that need to be
sure that `reference-barrier` is defined can import (srfi :1124
ephemerons).

> I expected (scheme *) libraries to work like that, but it has its own voting process, so I don't know if it's suitable to try the RFC v Protocol model.

In the long run, I think we need versioning of the (scheme *)
libraries; otherwise (unless R7RS has already found the ideal, which
is unlikely), some later standard will have to choose just another new
prefix (we already had the switch from rnrs to scheme).