Am Mi., 23. Nov. 2022 um 00:01 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sun, Nov 20, 2022 at 9:15 PM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>
>>
>> Are you particularly concerned about SRFI 162 recommending changes to SRFI 128?  I'm not sure what to do about that.  Technically, it is proposing changes by making a new SRFI, but I see how it isn't a good idea for a new SRFI to change the meaning of an old SRFI in such a way that the meaning of importing the old one changes.
>
>
> It depends on the meaning of "meaning".  SRFI 162 doesn't recommend an incompatible change to SRFI 128; it only recommends a set of extensions.  In this particular case it is adding new identifiers, so there is an incompatibility in the sense that if you import (srfi 128) you may get more exported identifiers if SRFI 162 is incorporated than if it is not.
>
> On the other hand, if `foo` is a procedure declared in SRFI X that supports two arguments, and in SRFI Y the procedure 'x' supports two or three arguments, there is a technical incompatibility in the sense of R6RS but not in the sense of R7RS.
>
> If on the gripping hand we are to say that *any* change to a SRFI requires a marker of incompatibility including bug fixes, then we need a completely new SRFI number for each fix, in which case we cannot import both SRFI M and SRFI N.  If we are to avoid that, we must have libraries (srfi 128), (srfi 162), and (srfi 162 butnot 128).  Once we get up to five possible bug fixes, we end up with 32 libraries.
>
> Using features makes things worse: we need a new feature name for every bug fix, and we need a mechanism to say which features a given library supports.

This is why I propose to give version numbers to bugfix revision of a
SRFI.  A Scheme system that has a way to deal with library versions
(e.g. R6RS and, possibly, R7RS-large) can then use these officially
assigned versions.

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.

In the case of SRFI 128/162, a PFN should be added to SRFI 128,
describing what additions are there and giving it a new version number
as well.

As the example of make-coroutine-generator shows, it is not only about
breaking interfaces.  For another example, consider the comment about
vector-sort! in SRFI 132.  It says that no O(n log(n)) algorithms
running in constant space are known.  Suppose, miraculously, someone
found such an algorithm and a simple one on top.  So we would like to
amend SRFI 132 with this extra guarantee.  This would not justify a
whole new SRFI, but a bump from version (1 0 0) to (1 0 1), say.

Marc