Email list hosting service & mailing list manager

Re: Need a general place to stash SRFI implementations needed by other SRFI implementations hga@xxxxxx (21 Aug 2020 11:32 UTC)

Re: Need a general place to stash SRFI implementations needed by other SRFI implementations hga@xxxxxx 21 Aug 2020 11:32 UTC

> From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>
> Date: Thursday, August 20, 2020 9:16 AM
>
> Am Do., 20. Aug. 2020 um 16:10 Uhr schrieb <xxxxxx@ancell-ent.com>:
>
>> I think they should be completely separate.  To take my current
>> worst case, the POSIX Terminal fundamentals SRFI 205 will depend
>> [lots of new SRFIs, including a new plist one. ] And the latter is
>> what prompted this thread of discussion, since your sample
>> implementation depends on SRFI 64, and I'm discovering (chibi test)
>> is not an acceptable substitute for how you exercise SRFI 64 in
>> useful ways.
>
> I've once asked Alex to include SRFI 64 in the Chibi distribution.
> Maybe, if you ask him as well, we have higher chances that it will
> eventually land there. :)

This a bit akin to one of the worst aspects of Linux prior to systemd.
The project refuses to define a stable device driver ABI, resulting in
many things.  Of particular interest, possibly world historical, is
that that prevents anyone without insanely deep pockets from creating
their own operating system using the Linux device driver set.

Relevant to your point, from release to release when there's an ABI
change, Linux device drivers break.  A *lot*, and many of us have
scars from this.

Every library Alex officially adds to the Chibi Scheme distribution
incurs an additional demand on his time to keep it working.
Especially given Snow, it makes sense for him to limit them.

> [ The easier it is to test, the more bugs will be found in both SRFI
>    and Scheme implementations ]

- Harold