[R6RS] Library / filesystem mapping
Anton van Straaten
anton at appsolutions.com
Sat May 19 10:45:40 EDT 2007
> In this approach, I'd prefer that the version number be in the filename
> even for the most recent version so we don't have to treat it as a special
> case and have to invent some new protocol for representing version numbers
> in the files.
> The most recent version foo.<version>.sls could always be copied (or
> linked) to foo.sls so that the implementation wouldn't have to search for
> the latest version, except of course when the relational version number
> operators are used.
I agree with all the above.
One tangential observation is that the implementation may still have to
search for the latest version if multiple file extensions are supported.
> One more thing: we may want the actual pathname for, e.g., (x y z (a b))
> to be:
> That is, have the last library name component appear both as the last
> directory name in the path and as the filename root. This is to give
> different paths to (foo bar (3 4)) and (foo bar.3 (4)). Of course, we
> could instead discourage people from using numeric extensions like .3 on
> their library names.
Good point. I'm inclined towards the discouragement approach, because
it gives simpler names. People can always use names like bar-3.
This is also affected by Will's suggestion of ignoring some set of
special characters in library names. Will suggested only supporting
ASCII alphabetics, IIRC; that seems a bit *too*
lowest-common-denominator to me, but I don't have any sense of what
platforms might be affected by allowing numbers, hyphens, underscores
etc. in filenames.
Two more questions about requirements for anyone who has opinions on this:
1. Should we specify some kind of manifest format, to support
machine-readable metadata about a library, such as author name,
description, home URL, etc. (and possibly optional properties)? This
would presumably be an optional file with a standard name in a library's
top-level directory, containing either an sexp to be read as data, or
perhaps even a library which implements a standard interface. The
latter would be a bit more work to define, but it would support access
to library metadata without knowing where the metadata file is, by
exploiting the implementation's mapping between libraries and the
2. Should we recommend an archive format for distributing libraries, and
if so, what? I assume that the format should be something fairly easily
generated and read from Scheme code. I know PLT has code to handle the
gzip format, which is used in Planet. Gzip may inhibit direct handling
of the packages by users on Windows and Mac, although newer archive
clients are better at that.
(I'm ignoring cryptographic signing of library packages as being out of
scope for now.)
More information about the R6RS