I have noticed that some of the SRFI sample implementations follow a file system layout that makes them directly usable with Gambit's decentralized module system that can automatically install libraries from git repositories.  However the layout is not optimal and small layout changes could improve the situation so I would like to propose that some recommended standard layout and naming convention be followed by the SRFI editors and authors of SRFI sample implementations.

Let me explain with the recent SRFI 233 sample implementation that is compatible with the decentralized module system of Gambit and allows using it without prior installation:

$ cat test.scm
(import (github.com/scheme-requests-for-implementation/srfi-233 srfi 233))

(define a (make-ini-file-accumulator (current-output-port)))
(a "start of INI file")
(a '(sect prop1 "foo"))
(a '(sect prop2 "bar"))
$ gsi -:whitelist=github.com/scheme-requests-for-implementation test.scm
; start of INI file
[sect]
prop1=foo
prop2=bar

Gambit uses a whitelist approach to indicate which git repositories are trusted for automatic installation.  The whitelist can be specified on the command line, as above, or by a global whitelist declaration.  Alternatively the SRFI can be manually installed with:

$ gsi -install github.com/scheme-requests-for-implementation/srfi-233

It would be nice if the “import” form

(import (github.com/scheme-requests-for-implementation/srfi-233 srfi 233))

could be made less clumsy, i.e. removing the repetition in the name like these alternatives:

1) (import (github.com/scheme-requests-for-implementation/srfi-233))

2) (import (github.com/scheme-requests-for-implementation/srfi 233))

3) (import (github.com/scheme-requests-for-implementation srfi 233))

4) (import (github.com/scheme-requests-for-implementation/233))

The middle two of these work because Gambit maps library references to file system paths by adding a “/” between parts, so they are equivalent to:

(import (github.com/scheme-requests-for-implementation/srfi/233))

Unfortunately this would require all SRFIs to be in the same git repository (named “srfi”) so it is not ideal for assigning editing rights.

My preference is thus #4 which simply uses the SRFI number as the name of the repository.

The only thing needed for this to work with Gambit would be to rename the “srfi-233” repository to “233” and to rename its “srfi” subdirectory to “233”.

Files related to SRFI 233, such as the unit tests “srfi-233-test.scm”, can also be put in the “233” subdirectory. Using the number of the SRFI in the subdirectory name also allows grouping many SRFI sample implementations in the same place, which could become useful in the future.

So for the sample implementation of SRFI <N> the layout would be:

- repository github.com/scheme-requests-for-implementation/<N>:
  - <N> subdirectory
    - <N>.sld
    - other files that are part of the sample implementation, such as <N>-impl.scm, unit tests and data files
  - other files related to the sample implementation, such as a README.md, makefile, etc

In addition to this basic layout change, let me propose a layout for unit tests and demos.  The SRFI libraries designed for Gambit have adopted the convention of naming the test file “test.scm” (or .sld) and putting it in a “test” subdirectory of the directory containing the SRFI library (and similarly for a “demo” subdirectory containing a demo).

In other words the library “(srfi 233 test)” is a library containing the unit tests of the library “(srfi 233)”.  Similarly “(srfi 233 demo)” contains a demo.

This essentially creates sublibraries for testing and demo.  This allows testing the SRFI library by adding “/test” to the library reference (or “/demo” to run a demo).  For example:

$ gsi srfi/4/test
*** all tests passed out of a total of 1330 tests
$ gsi srfi/0/demo
Using Gambit.
Demo source code:

;; Many Scheme implementations including Gambit have a builtin
;; definition of cond-expand, so (import (srfi 0)) is not needed.
;; This program can be run with various Scheme systems like this:
;;
;; $ gsi srfi/0/demo                  # Gambit
;; $ guile lib/srfi/0/demo/demo.scm   # Guile
;; $ csi -s lib/srfi/0/demo/demo.scm  # Chicken

(cond-expand
 (gambit  (print "Using Gambit.\n")
          (define-cond-expand-feature foo)) ;; define foo feature
 (guile   (display "Using Guile.\n"))
 (chicken (display "Using Chicken.\n"))
 (else    (display "Using an unknown Scheme implementation.\n")))

(cond-expand
 (foo (print "Demo source code:\n\n" (read-file-string (this-source-file))))
 (else))

If this convention was used by the libraries on github.com/scheme-requests-for-implementation it would help programmers use those libraries.  A demo is particularly useful to give programmers a quick-start in using a library.

Marc