To see it from a different perspective (and taking SRFI 116 as an example).

What is the correct option from those below?

(1) An implementation of SRFI 116 has to support SRFI 114 comparators.
(2) A (future) implementation of SRFI 116 has to support SRFI 128 comparators.
(3) An implementation of SRFI 116 either has to support SRFI 114 or
SRFI 128 comparators or both.

(If option (2) or (3) is chosen, the meaning of an implementation of
SRFI 116 is obviously time-dependent.)

Marc

Am Mi., 23. Nov. 2022 um 16:22 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@gmail.com>:
>
> Am Mi., 23. Nov. 2022 um 16:16 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
> >
> > > 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
> > > - ... ... ...
> >
> > You have a tendency to believe that precision will solve the world's
> > problems. While precision has its place, I've been trying to hint that
> > it causes as many problems as it solves.
>
> I have to ask this again: How is all your text above and below related
> to my observation above that - de facto - SRFIs didn't remain as
> stable as sketched by Marc?  This observation is independent of the
> question of whether SRFIs should be set in stone or whether versioning
> is needed if they are not.
>
> > Sometimes we should take a big hammer to a problem. It doesn't pay to be
> > precise about details when the big picture is veering toward absurdity.
> >
> > Library design is as much a social problem as a technical one. Social
> > problems are solved by authority. Authority comes from confidence, which
> > is eroded by amendments and course corrections to what one did before.
> > SRFI 116 switched from one kind of comparator to another. Are we to
> > believe that the right kind of comparator has now been found? I have my
> > doubts.
> >
> > I don't know whether you listen to jazz, but the landmark albums were
> > recorded with very few takes and edits. A Love Supreme was done in one
> > day. The result is canonical, not Platonic. That's the spirit of SRFI.
> > That's why SRFI 1 is so widely respected and relied upon. Nobody thinks
> > it's God's word on lists; everybody uses it.
> >
> > There's a place for publishing things that aren't landmarks, but that
> > inherently gives rise to different process requirements. I'll propose a
> > big hammer in a new thread.
> >
> > > 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.
> >
> > It's intentionally difficult so that people don't submit incremental
> > improvements to earlier stuff, but submit them in big batches instead.
>
> Where do you find this statement backed up in the SRFI documents; a
> lot of SRFIs like, say, SRFI 8 are incremental improvements.