> From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>
> Date: Wednesday, August 19, 2020 3:16 PM
>
> Am Mi., 19. Aug. 2020 um 22:01 Uhr schrieb <xxxxxx@ancell-ent.com>:
>
>> Arthur quite reasonably wants SRFIs to stop bundling other SRFI
>> implementations with their supplied implementations.  I.e. don't
>> bundle your own SRFI 64: A Scheme API for test suites in your brand
>> new SRFI.
>
> SRFI 138 describes the "-A" option to *append* directories to the
> library search path. Chibi-Scheme and many other Schemes implement
> this option. As long as you use such a flag when using the code of a
> SRFI, the bundled libraries will only be used when they are not
> present in your system.
>
> I still think that this is the easiest and gives the best user
> experience.

Thinking about it since I sent my message, setting up your library
directory search order to provide your preferred set of native,
Snow/whatever, and supplied by the SRFI libraries also strikes me as
the best solution.

You have to do one block of work when you start engaging with a SRFI's
libraries, you have to do that anyway to get the SRFI's
implementation if it is, as it should be, packaged as a regular SRFI.

We can provide guidance in a document inside the srfi subdirectory of
the SRFI as I do for Chibi Scheme.  It's the only one modern one I've
been using, it's just right for my purposes, no disrespect intended
towards other implementations.

If we accept this unfortunate necessity instead of Arthur's ideal, we
should create a convention for including auxiliary SRFIs in a SRFI's
repoes.  In particular, they should be separated both from the SRFI's
sample implementations, and each other, so the user can pick and
choose which ones he wants.

> [ Snowfort discussion, which has proven to be very fruitful, but not
>   necessarily solving this problem in general. ]

As a for instance, due to my style of focusing, it would be a lot of
effort I'm not interested in doing to put up a newer version of SRFI
64 there, since I'd first need to test if it works for a bunch of
Scheme implementations and then fix those problems.  Bundling
auxiliary libraries in a SRFI's repo allows a relaxed process as the
SRFI moves towards finalization to fix problems for anyone who's using
a Scheme that turns out to be incompatible one or more of them.

- Harold