Am Mo., 24. Okt. 2022 um 21:00 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sun, Oct 16, 2022 at 3:11 AM Daphne Preston-Kendal <xxxxxx@nonceword.org> wrote:
>
>>
>> 1. SRFI should not become a dumping ground of (effectively) documentation for random libraries that end up with only one implementation each, but a repository of improvements to the core Scheme language.
>
>
> I believe this is much too absolute and in fact a "no true Scotsman" fallacy.  SRFI 1, for example, is not an improvement to the core Scheme language.  In fact, other than the R6RS prototype SRFIs I think there are very few SRFIs that meet that criterion if interpreted strictly.  The vast majority of SRFIs have more or less portable implementations and therefore do not , though I don't have a count of them (perhaps Arthur does); I know that only a handful have no implementations at all.

I think there is no mathematically precise measure of whether a
particular proposal should be better packaged as a SRFI or as a
portable library instead.  I don't think that whether a portable
implementation exists is not a good measure.

Of course, for something like SRFI 93 (syntax-case) this is pretty
clear that it only works as a SRFI.  But I also think that something
like SRFI 158 (generators) makes sense as a SRFI because it is meant
to provide a fundamental structure that is meant to be used by many
other SRFIs, other libraries, and idiomatic code. A case for SRFI 1
because it introduces idiomatic procedures like "fold".  Even the core
language includes things (like "unless") that could have well been
outsourced to a portable library.

On the other hand, there are SRFIs like SRFI 161 or SRFI 233 where it
becomes clear to me what Daphne means.

In any case, a sister structure would make sense because it could also
work as an incubator for later SRFIs, which hopefully helps to improve
the quality of proposals further.

>
> [MN-W:]
>
>> > SRFIs should ship with Scheme
>> > implementations and the sample implementation should not be copied
>> > verbatim but adapted for the maximal functionality or efficiency on a
>> > particular implementation.
>
>
> It seems clear that implementers are unwilling to do this.  It happens in Chicken because the load of moving SRFIs to the Chicken package manager tends to be small (partly because I historically have used Chicken for development) and because it is distributed over many Chickeneers.  This isn't happening for most Schemes AFAIK.

For this, it would help if the number of SRFIs were reduced by moving
those where the portable implementation is not meant to be touched to
a library repository.