Am Mi., 23. Nov. 2022 um 14:58 Uhr schrieb Marc Feeley
<xxxxxx@iro.umontreal.ca>:
>
> I am in general agreement with Arthur, Lassi and Shiro’s point of view that when a SRFI is finalized, it is exactly that… final!  It can’t be changed otherwise previously working code that imports a SRFI might break if something (of substance) is changed in that SRFI.  The changes that are allowed are those that are typos, or blatant errors (not using the correct name in an example, wrong result specified by an example, broken hyperlink to a reference that has moved, a sample implementation that doesn’t agree with the spec of the SRFI, …).  Nothing of essence in a SRFI should change after finalization.  I was part of the group that instigated the SRFI process and I remember that this was one of the reasons why SRFIs are identified with a number.  We didn’t want a well-known name like “list”, “hash-table”, etc to be reserved by a SRFI that would eventually become deprecated, forcing a “better” SRFI to be called “list2”, “better-list”, etc.  The SRFI numbers are precise identifiers of a spec forever.  SRFI names have a transitory nature (in 20 years what will be called the “list” SRFI may be some SRFI number other than 1).
>
> If a SRFI contains a design error, such as a feature that just doesn’t work well with other features that are possibly added after the SRFI is finalized, then so be it.  A revised SRFI with a better design and new number can be proposed, discussed and finalized.  To me that is how the SRFI process was designed to work.

I think the main point is that this is not how it has always been
handled.  Just a few examples:

- The SRFI 1 erratum of 2022-10-22, while very reasonable, is outside
the narrow scope painted above.
- How can a program know whether a particular implementation of SRFI
116 uses SRFI 114 or SRFI 128 comparators?  If we take the above
strictly, PFN #2 must be ignored and implementations must continue to
use SRFI 114 comparators.
- The SRFI 124 erratum is also outside a narrow scope of fixing blatant errors.
- PFN #1 and #3 of SRFI 128 would have to be ignored by implementation
in the strict sense.
- The order of vector-cumulate was later changed in SRFI 133
- ... ... ...

I am not against declaring that SRFIs should be immutable in principle
once finalized, but then we should pull it through and make publishing
revisions (under new numbers) of SRFIs a simple and straightforward
task.

Marc

> This does not mean that I’m against versioning libraries.  Versioning is a “fact of life” for living code that evolves over time.  However each version should designate a specific immutable snapshot of a library so that when a specific version of a library is used today and in 100 years it refers to the same snapshot of the library.  A SRFI is not a library, it is a spec of a feature (or group of features) to be supported by a Scheme implementation.  Often the feature is implemented as a system specific library or a portable library, and these libraries may evolve over time (to repair bugs, improve performance, etc) and consequently they may be versionned.  So the implementation of the SRFI may be versionned, but not the SRFI itself, which is the spec.

>
> Marc
>
>
>
> > On Nov 23, 2022, at 6:45 AM, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
> >
> > 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).
>
>