Email list hosting service & mailing list manager

Re: Need a general place to stash SRFI implementations needed by other SRFI implementations Marc Nieper-Wißkirchen (20 Aug 2020 14:16 UTC)

Re: Need a general place to stash SRFI implementations needed by other SRFI implementations Marc Nieper-Wißkirchen 20 Aug 2020 14:16 UTC

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 on at least one SRFI 170 procedure, and if you import a full SRFI 170 library it'll depend in SRFI 174 POSIX Timespecs (albeit trivially, and probably not needed for SRFI 205).  Both need SRFI 198 Foreign Interface Status, and that will soon depend on a plist SRFI that's in the polishing stage prior to submission to Arthur.  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. :) SRFI 64 has the advantage that it has a
standardized written specification. The other SRFI concerned with
tests is SRFI 78, but that one is not nearly as powerful.

> Although encouraging the adding of one sort of "fuss" is a goal: if the sample implementation has an error which makes it fail with a different but correct library of a Scheme implementation that it hasn't yet been tried with ... or the reverse can help that implementation improve its quality.  So I claim making it as easy as possible to mix and match the sources of libraries is a good thing.

Excellent point.

-- Marc