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.

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.