[R6RS] Library / filesystem mapping

[Anton van Straaten]

Kent wrote:
> 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:
> 
>    x/y/z/z.a.b.sls
> 
> 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 
filesystem.

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.)

Anton