> On Apr 25, 2021, at 7:13 AM, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> Yes, SRFIs can be rewritten but it's somewhat costly. The thing is that for many problems we have started writing SRFIs without a clear idea of the problem domain, which is the main reason we haven't kept to the 90-day deadline in the SRFI guidelines.
>
> The solution is to do most design work using a lightweight process, and only submit the result as a SRFI once it is stable.

+1

I would say this is the biggest problem with the SRFI process.  In the SRFI process a proposal is made, discussed and changed in a mostly academic fashion with typically minimal implementation and usage experience.  A SRFI would be much more valuable if it was a design proven through some amount of practical use to “debug” the design and iron-out the details.  If a new “more lightweight” process is created, it could feed the SRFI process and also stand on its own (some contributions are really more RnRS libraries that don’t need to become SRFIs if they have a documented API).

As I have argued in the past a decentralized library/package management system that is supported by many Scheme implementations could serve this purpose well.  It is “decentralized” in the sense that the libraries are stored and maintained in web-accessible user created repositories (github, gitlab, …).  This does not preclude having a centralized “library aggregator” that lists all of the available libraries with their URLs.

Marc