Date: Thursday, August 20, 2020 10:45 AM
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.
Sorry, I don't quite understand which antecedent you're referring to with "this unfortunate necessity." Do you mean including a document explaining how to run the tests, or a Makefile, or scripts? Or do you mean including copies of other SRFIs? I certainly don't object to the former.
Sorry, the latter, the former is already my SOP. The existing general repositories do not seem to be sufficient to remove other SRFIs from SRFI repoes, so as I see so far, these auxiliary SRFIs will either have to stay there (which you'd like to end) with the above separation, or you could, for example, provide a GitHub scheme-requests-for-implementation/srfi-artifacts repo for them, perhaps with a subdirectory for each SRFI that needs it.
That's just off the top of my head, but I will soon be submitting an implementation from Marc for the plist work in progress (polishing stage) SRFI, and it depends on SRFI 64. He's supplied one that works with Chibi Scheme; the SRFI 64 sample implementation does not, and he says the same is true for the version in Snowfort. I'm not the right person to fix the latter two problems, you want someone who regularly deals with lots of different versions of Scheme, so the above is my narrowly focused analysis with possible solutions.
- Harold