Re: Making SRFI go faster Lassi Kortela 25 Apr 2021 10:57 UTC

> You have my support. We agree on the goal to make it easier to
> contribute to Scheme, and help Scheme progress faster.

Thank you! And thanks for working on scheme-live so far.

> It is also a technical issue, the Scheme world is so diverse in terms
> of implementations and goals that it is difficult to contribute to
> Scheme without a dedicated Scheme implementation for the purpose of
> the SRFI process and RnRS.

It is, but a big collection of working code would also motivate porting
work. Unit testing and CI could be solved in one place, especially if we
use a monorepo. Then adding tests for any new code can immediately use
the work that has gone into those tools, and for portability there are
lots of existing cond-expand's to use as examples for how to do it.

A sample implementation of Scheme and SRFI would be awesome but I assume
it's too difficult to pull off, unless an existing implementation is
gradually turned into the sample implementation by adding features.

>> Would the people around SRFI be interested in formalizing the
>> lightweight work we already more or less have?

> I do not understand the question. What needs formalization?

Really just blessing a monorepo with "official" status. The community is
already doing work like this, but it's split into many libraries around
the net, with different people working on each library. If we had one
library that is known as a canonical one, with many people working on it
(roughly, the people now writing SRFIs, plus anyone else who wants to
join) people would slowly learn to trust it.

The library collections like Schemepunk, Yuni, Spells, Spheres, etc. are
especially interesting as prior art. These are like Scheme Live, but
tend to have one maintainer who stops working on it after a few years.
Ideally we could roll all of them into one collection with enough people
to ensure continued maintenance.