Email list hosting service & mailing list manager

Errata, PFNs and versioning of SRFIs Marc Nieper-Wißkirchen (27 Oct 2022 15:55 UTC)
Re: Errata, PFNs and versioning of SRFIs Arthur A. Gleckler (27 Oct 2022 18:01 UTC)
Re: Errata, PFNs and versioning of SRFIs Marc Nieper-Wißkirchen (27 Oct 2022 18:25 UTC)
Re: Errata, PFNs and versioning of SRFIs Arthur A. Gleckler (27 Oct 2022 19:12 UTC)
Re: Errata, PFNs and versioning of SRFIs Marc Nieper-Wißkirchen (27 Oct 2022 19:52 UTC)

Re: Errata, PFNs and versioning of SRFIs Marc Nieper-Wißkirchen 27 Oct 2022 19:52 UTC

Am Do., 27. Okt. 2022 um 21:13 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> SRFIs are supposed to be unchanging once finalized.  Errata and post-finalization notes are exceptions, but are intended to be rare.  The goal should be to get every implementation to use the corrected version of the SRFI as quickly as possible.  Implementations can use tags to specify how up-to-date they are.  I don't want to do anything to encourage the idea of picking and choosing between versions.  Encoding the version of the SRFI into the source code would do this.

As errata and PFNs are exceptions, I expect most library versions to
stay at 1.0.0, which is just fine.  This idea is not to promote
picking but to drop old versions.  This is easier as when this would
introduce silent errors.  We have discussed how it would be best if
more Scheme implementations provided adapted native implementations of
some SRFIs (e.g. for those where efficiency counts).  If this happens,
we will see more SRFI implementations of varying currentness in
existence. Importing an old version of a library implementation should
not have to go silent because otherwise, hard-to-find bugs may be
covered.  Encoding a version of a SRFI in some way into the source
code is, in my opinion, a good thing.  When I have a SRFI
implementation, I would immediately be able to see whether all PFNs
are already incorporated, for example.

There was the following admittedly very skeptical comment of Mark H.
Weaver: https://lists.gnu.org/archive/html/guile-devel/2020-08/msg00000.html.
But I think he makes a point about breaking code in the last
paragraph.

Anyway, I can live without versions (I did it before!) even though I
think they would be an improvement; so if you are strongly opposed to
the idea, there's no need to follow up on the idea, at least not in
the near future.