> On Oct 18, 2022, at 5:22 PM, Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>
> 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?

If github.com/scheme-requests-for-implementation was the only place where libraries can be found then yes this convention would be fine.  But there are other libraries than SRFIs and other “consumers” of the sample implementations than humans (e.g. package installers).

Given the special status of the SRFI web site in setting Scheme standards, I would expect that it follow a standard layout for libraries so that it is easier to remotely access the sample implementations without making a special case for each one, or for SRFIs (vs. other sites where libraries can be found).

I’m thinking of extending Gambit’s define-module-alias form to allow a pattern language, similarly to quasiquotation and some “match” macros, so that (import (sample-srfi 233)) can be mapped to the sample implementation using something like

(define-module-alias (sample-srfi ,N) (github.com/scheme-requests-for-implementation ,N srfi ,N))

Note that with the current layout srfi-${N}/srfi/${N}.sld the alias needed would rather be

(define-module-alias (sample-srfi ,N) (github.com/scheme-requests-for-implementation srfi-,N srfi ,N))

in other words the repository name needs to be constructed by prepending “srfi-” to the SRFI number.  This is not very Schemey (indeed syntax-rules does not allow such a thing).

Also the choice of “srfi” as the subdirectory where the sample implementation is stored is obviously very specific to SRFIs.  Why impose a layout for SRFIs that will clearly not be followed by other R7RS libraries?

I propose that for a library “X” (SRFI or not) the source code file “X.sld” is stored in a subdirectory named “X”.  Moreover, for SRFI N the repository would be called “N” rather than “srfi-N”.

This would allow the simple alias definition:

(define-module-alias (sample-srfi ,N) (github.com/scheme-requests-for-implementation ,N))

In fact, because the current define-module-alias form defines a mapping for a module name prefix, it would work with the current define-module-alias with simply:

(define-module-alias sample-srfi github.com/scheme-requests-for-implementation)

I hope that a SRFI for a library layout can be written along these lines and that the SRFIs on github.com/scheme-requests-for-implementation will adhere to it when possible.  This is a good place to start discussion on layout concerns that the SRFI should address.

Marc