Am Di., 18. Okt. 2022 um 23:23 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> On Sun, Oct 16, 2022 at 5:08 AM Marc Feeley - feeley at iro.umontreal.ca (via srfi-discuss list) <xxxxxx@srfi.schemers.org> wrote:
>
>>
>> As a Scheme system maintainer I would like to avoid (or greatly simplify) this repackaging of the sample implementations.  Surely the SRFI process/editors can suggest a standard layout for the sample implementation to automate the repackaging.  Now that the sample implementations are on github, let’s not miss this opportunity to have a layout of the repos that is uniform.  The main point to resolve is simply where the .sld file is stored (the name of the file, and the subdirectory’s name).  Other aspects of the layout are surely interesting but somewhat secondary.
>
>
> I'm partial to the convention that has become common in recent SRFIs:
>
> srfi-${N}/srfi/${N}.sld
>
> It's concise and clear.
>
> Often, authors put tests at the srfi-${N}/ level, e.g. at srfi-${N}/srfi-${N}-test.scm. I'd rather see them under the srfi directory, without a "srfi-" prefix, e.g. at srfi-${N}/srfi/${N}-test.scm. I don't think that should cause problems with loading the tests when they're not needed.
>
> What do people think of that convention?

I have started putting libraries into a "lib" directory and giving
this path explicitly to the Scheme interpreter/compiler.  This way,
one can make universally sure that no artifacts that can be mistaken
for libraries are picked up by the implementation when searching for
libraries to load them. So, "lib/srfi/:227.sls" and
"lib/srfi/227.sld", for example.

In general, I think, it should be left to the SRFI authors.

The really interesting SRFIs are anyway those that are not
(efficiently) implementable in a portable way.  All other SRFIs do not
have to rely on the SRFI process.