I agree that SRFI sample implementations are first and foremost a demonstration that a SRFI can be implemented, usually as portably as possible.  It can serve as a starting point for the maintainers of a Scheme system to adapt it for optimal integration and speed on that Scheme system.

But Scheme system maintainers are typically quite busy with other things, so lowering their workload is a good thing so that other aspects of the Scheme system can also get some love.  Currently there are a large number of SRFI authors, and usually one or a small number of maintainers for a given Scheme system.  This means the typical path of a maintainer for supporting a SRFI is to take the sample implementation verbatim and do as little changes to it as possible.

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 agree with Daphne that a decentralized package/library/module system is the best solution for the sharing of Scheme libraries.  We all use github, gitlab, etc in our daily work to share code so why should the Scheme systems not take advantage of this powerful tool?  This does not exclude also having a registry of popular packages, and there could be several registries, but I view their role mostly as a way to find libraries rather than a distribution mechanism.

For completeness, let me explain the define-module-alias form supported by Gambit.  Here’s a sample use:

$ cat _setup_.scm
(define-module-alias sample-srfi github.com/scheme-requests-for-implementation)
$ cat main.scm
(import (sample-srfi srfi-233 srfi 233))
...

A define-module-alias form indicates a mapping from a library name prefix to a new prefix.  In the above example, the library name (sample-srfi srfi-233 srfi 233) is equivalent to (github.com/scheme-requests-for-implementation srfi-233 srfi 233).

This gives a level of abstraction in the library names.  With define-module-alias an abstract name, here sample-srfi, is mapped to a specific github repository.  The aliasing needs to be external to the main file so that the meaning (mapping) of its import forms can be changed without modifying the file.  This is useful to transition between testing and production, or to change library providers.

This is why the define-module-alias forms are put in a file with a fixed name (_setup_.scm) that is searched by the module system.  The search algorithm looks at the directory containing the main file, then the parent, then it’s parent, etc until the _setup_.scm file is found.  This implements a kind of lexical scoping using the file system (the aliases of the closest _setup_.scm file will have precedence over the ones further up the tree).

Gambit’s approach is still a WIP and I’m open to suggestions.  For example, maybe a module alias should be defined similarly to a procedure:

(define-module-alias sample-srfi (lambda rest …do-domething-intelligent-with-rest…))

so that the remaining parts of the library name can be used in the mapping, for example mapping (sample-srfi 233) to (github.com/scheme-requests-for-implementation srfi-233 srfi 233) .  On the other hand, perhaps a pattern language similar to the one for syntax-rules is good enough.  I’m not sure however how that would work in this specific example since srfi-233 needs to be constructed from 233 (unless my suggestion of renaming the SRFI repositories from srfi-<N> to <N> is adopted...).

Marc

> On Oct 16, 2022, at 4:56 AM, Lassi Kortela <xxxxxx@lassi.io> wrote:
>
>> I would love it if someone were to write a SRFI to define a programmable way to control how a Scheme implementation maps library names to pathnames.
>
> I've had something in mind for more than a year, but the details are difficult. It's based on the Smalltalk idea of protocols, as well as Unix/Plan 9 namespacing.
>
> One thing has become clear to me: it should be a layered approach. A full-blown rewrite system is too much for the smallest implementations.
>
> I'll write up a detailed proposal when I can find the time.
>
>> MIT Scheme has an undocumented way to do that now that's still under experimentation.
>
> Can you link to the source code?
>
>> It would be great, for example, to be able to allow any library in the (srfi ...) "namespace" to try all of the popular conventions rather than just using the implementation's standard convention.
>
> As long as the mechanism is general, not a collection of special cases.
>