Regardless of whether the spec or the implementation comes first or whether the interface is stable or not, I think there is one important point where SRFIs would differ from the libraries in the proposed collection we are talking about here.

Many libraries are written to get things done or to support a particular programming style. Such libraries have their place in such a collection even when they shouldn't be standardized in any way (e.g. by turning them into a SRFI). One example is the λ syntax of Schemepunk. It is the same as the regular lambda except for treating (λ x e) as (lambda (x) e) instead of (lambda x e). This makes the behavior of λ rather irregular (so shouldn't go into a standard), but this doesn't mean that it shouldn't be published to used by those people who like this kind of idiosyncrasy. In fact, this may simplify some SRFI discussions when SRFIs can concentrate on those things where there is consensus and where no idiosyncrasies of a particular programming style are involved because everything else could be moved to the proposed collection of libraries.

Am Mo., 26. Apr. 2021 um 02:28 Uhr schrieb John Cowan <xxxxxx@ccil.org>:


On Sun, Apr 25, 2021 at 4:29 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
 

The starting point should be that it's implementation first (or implementation and discussion), and once the implementation stabilizes, a stable specification is the end product.

In other words, the opposite direction than what SRFI is currently using.


It's still the case that SRFIs work like that to a fair extent.  The main exception is the work that I'm doing: I have time to write specs (and I enjoy writing them), whereas writing the corresponding code requires not only more time than I have now, but quite possibly more time than I will ever have.

I think what is going to happen fairly soon (after the Orange Edition is ballotted) is that I migrate my remaining specs out of johnwcowan/r7rs-work and into pre-srfi repos, and then get out of the SRFI business altogether.  I will focus on WG2 duties, and will arrange SRFIs into ballots based on availability rather than subject matter.

A library collection would basically be the same thing, but putting all libraries in a monorepo with collective ownership instead of separate repo per library, each owned by one person.


The trouble with a monorepo is "once mono, always mono"; it is a pain in the ass to extract a particular subtree into a SRFI repo, whereas if each pre-SRFI is in its own repo it is easy to transfer it to SRFI space and archive the pre-SRFI space.  Ownership isn't really an issue: everyone who is an owner of the pre-srfi org is also an owner of all the individual repos, and there's no reason why everyone who wants to participate can't be added as well.  (Of course there will be some participants who want nothing to do with GitHub.)




John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
You annoy me, Rattray!  You disgust me! You irritate me unspeakably!
Thank Heaven, I am a man of equable temper, or I should scarcely be able
to contain myself before your mocking visage.  --Stalky imitating Macrea