[R6RS] Library / filesystem mapping

[William D Clinger]

Anton wrote:
> 1. In order to support the distribution of portable libraries, since
> <library name>s don't contain filenames, I assume that the document
> should recommend a standard file extension which will be used to
> construct a filename from a library name.  Are there any preferences
> about whether the extension should, or shouldn't, be ".scm", ".ss", or
> something else?

The most widely recognized extension seems to be
".scm".  I'm kind of attached to ".sch", which has
been the standard extension in MacScheme and Larceny
since 1985 and was probably in use earlier.  Larceny
currently recognizes both ".scm" and ".sch", and
will probably continue to do so.

Just about any three-letter extension we choose will
conflict with someone else's.  A Google search on
'file extension .scm' turns up 1,050,000 pages; the
corresponding search for ".sch" turns up 741,000.
Kent's suggestion, ".sls", turns up 197,000 pages.
If we're going to pick a new extension, I'd suggest
".slf" for "Scheme library file", which has only
44,500 page hits.

> 2. It makes sense for the version number to be at or near the top of the
> file hierarchy for a library, so that beneath each version number is a
> tree containing only source for a single version.  I'm going with a
> hierarchy beginning with "6/rnrs/...".  If anyone thinks it should be
> "rnrs/6/...", or something else, please let me know.

I think it makes more sense for the version number
to come last, especially when you get into minor
subversions.  Consider the problem of searching
for the most recent version of a library whose
file name would be of the form

    /<initpath>/<versionpath>/rnrs/foo.slf

With the <versionpath> coming first, you'll have
a lot of directories to search before you find it.
With the <versionpath> coming last, you probably
won't have to search so many directories.

> 3. I'm assuming that sub-version numbers should be encoded in the
> filesystem using the typical period-separated approach, so that a
> <version> of (3 4 5) would be contained in a directory named "3.4.5".
> Whisper politely if you disagree; I haven't really thought through the
> impact of this on version number matching yet.

I suspect there are file systems and organizational
conventions in which numeric directory names don't
go over well.

I'd question whether version numbers should even
be represented as directories.  The most recent
version of library (rnrs foo) could be in
.../rnrs/foo.slf with the version number in its
source code, and older versions could have names
like .../rnrs/foo.6.5.4.slf .

> 4. Libraries whose names contain certain special characters, such as
> slashes, may need to have their filenames encoded.  An example is (rnrs
> i/o simple (6)).  Of course, it's possible to cheat and use
> "6/rnrs/i/o/simple", but I'm guessing that won't go over well.  However,
> anything else seems likely to be icky, I'm open to suggestions.

You guessed right.  I'd suggest forming the directory
name from the component names by ignoring all but the
ASCII alphabetic characters.  You'll should also
consider what to do with file systems that aren't
case-sensitive.

Will