I am very much in agreement with Marc Nieper-Wißkirchen:

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. But the current situation also makes SRFIs the easiest apparent way to get libraries into multiple implementations. That needs to change, or we’ll increasingly end up with the situation of libraries which shouldn’t really be SRFIs becoming SRFIs just to get them more widely supported.

2. To that end, we need a common package manager for multiple Scheme implementations. We have a number of attempts such as Snow and Akku, but Marc Feeley’s decentralized approach seems like the best one to me so far. (A decentralized approach such as this makes supply-chain attacks Somebody Else’s Problem, for example.) I’ve had the rough details of such an approach sketched out for a while, but it would be a big effort to write the whole thing and make it actually work on multiple implementations.

Daphne

> On 16 Oct 2022, at 00:18, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
> While I am supportive of making it easier to install published Scheme
> libraries on a variety of Scheme implementations, I think the case for
> SRFIs is slightly different. Using the sample implementation directly
> should only be the second-best solution. 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. While I understand that many SRFIs have to
> be installed by users from the official SRFI repository using the
> sample implementation, if this is advocated as being particularly
> simple, it may seem that this is like the designed way to use a SRFI.
> I fear that it impedes the native adaption of SRFIs.
>
> Am Sa., 15. Okt. 2022 um 18:16 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>>
>> P.S. The problems we have with library filename mapping are a re-run of
>> the problems Linux and BSD distros have been experiencing with
>> filesystem layout for nearly three decades. Various proposals for
>> standardizing file locations have been made over the years. None of them
>> became universally accepted. In the end, the only system that is
>> convenient for distributors is if all pathnames used by a program are
>> configurable.
>>
>> Unix provides mounts and symlinks as tools that users, sysadmins, and
>> distributors can use to work around breakage due to clashing
>> conventions. I'm almost certain that we'll end up needing similar tools
>> in Scheme, and for the same reasons.
>>