Am Fr., 25. Nov. 2022 um 05:35 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> On Thu, Nov 24, 2022 at 2:39 PM John Cowan <xxxxxx@ccil.org> wrote:
>
>>
>> On the contrary, that is exactly what they are for.  See <https://srfi.schemers.org/about.html>:  "We write concrete, detailed proposals and sample implementations for libraries and other additions to the Scheme language, and we encourage Scheme implementors to adopt them."  A proposal is a suggestion, not a specification.
>
>
> I believe that you are both correct.  The SRFI process document used to say this:
>
> The total discussion period must not exceed 90 days. Active discussion or revision after 90 days normally suggests that a proposal has been revised at least 3 times and is not yet mature enough for standardization [emphasis added by Arthur]. At the end of the 60-90 day comment period, the authors can choose to withdraw the proposal. If the editors determine that insufficient time for discussion has followed a significant revision of the proposal, the proposal will be withdrawn.
>
> So the previous editors had a policy that seemed designed to discourage experimentation. That may have been wiser, but I decided to experiment because so much good discussion was happening.  I've been happy with the outcome, even if it hasn't been perfect.

Obviously, I have been and still am very happy about the outcome as
well, for otherwise, I wouldn't probably contribute to the process so
regularly.  What is good about the SRFI process is that there is
usually no final authority, but the author who judges the quality of a
proposal and whether it should be finalized or withdrawn.  This leads
naturally to SRFIs that, in hindsight, are not optimal and should be
ignored or revised, but I don't see a problem with it.  On the
contrary, existing SRFIs, their design novelties, and their design
errors (if there are any) can help future authors tremendously.

What I was critical of was the process by which SRFIs were voted into
the large language (and already given official names). But I think we
have dealt with these issues with our new WG 2 structure, which
includes the Committee C work.

Arthur, thank you for your remark on versioning, which can solve my
issues.  It can work if people are aware and have agreed on such a
scheme.  In particular, people need to be aware of a tag for a library
implementing the original version of a SRFI.  Would it be (srfi 1
final)?

Compatibility of your proposal with SRFI 97 has still to be checked.
For example, SRFI 41's library names are (srfi :41), (srfi :41
streams), (srfi :41 streams derived).  Now, with tags, do we have
(srfi :41 final), (srfi :41 final streams), (srfi :41 final streams
derived) or do we put "final" at the end?

I would still prefer numbers (when library versioning is available)
because they won't clash with a hypothetical (srfi :999 chapters
final) library (i.e. when a version name is actually a library name).
With version numbers, we don't have the question of how to order the
library name parts, and with names instead of version numbers, we
cannot easily express in code "an implementation that covers at least
erratum-1".  I still don't see why it shouldn't be possible to have a
little version information after each erratum or PFN entry so that
implementations can use them if they want.  Alternatively, we can
agree on the convention that versions look like (2022 7 19) (for an
implementation of everything up to the PFN/erratum added on
2022-07-19). So (srfi :1 (1999 10 9)) implements the original version
of SRFI 1, (srfi :1 (2022 10 22)) implements the new specification of
reduce-right, and (srfi :1) stays for any version.