Storing library source code as files in a hierarchical file system is a common way to support the use of standard tools for editing and other kinds of source code processing.
The following recommendation specifies a standard way to map library names to file names in widely-used file systems, using an approach in which each file contains exactly one library form. Following this recommendation will allow users to work with a familiar source code structure across implementations, and can also allow multiple implementations to share a common repository of library source code.
The form of a library name is specified in section on “Library form”. It can be expressed as follows:
(<identifier1> ... <identifiern> <version>)
where <version> is empty or has the following form:(<sub-version1> <sub-version2> ...)
Such a library name should be mapped to a file in the file system with a relative path formed by the concatenation of the following components:<identifier1> <sep> ... <identifiern> <xsep> <extension>
where <sep> is the platform-specific character (such as /) used to separate path elements (which are typically directory names); <xsep> is the platform-specific character (typically a period) used to separate parts of a file name; and <extension> has the following form:
<sub-version1> <xsep> <sub-version2> <xsep> ... sls
where sls is the recommended extension used to identify Scheme library source files.
Note that the resulting path is relative to some implementation-dependent root directory.
According to this mapping, the source code for a library named (mylib examples hello) would be stored in a file mylib/examples/hello.sls; the source code for a library named (mylib examples hello (0 4 2)) would be stored in a file mylib/examples/hello.0.4.2.sls.
A library source file may define a library with a library name consisting of the same sequence of identifiers as another library known to the implementation if each library name includes a distinct and non-empty <version>.
If a library source file defines a library with a library name for which <version> is () or empty, then the source file must similarly have no version embedded within its name. In that case, to avoid confusion, no other library with a library name consisting of the same sequence of identifiers, but with a non-empty version, should be known to the implementation.
This report does not describe a file system mapping for compiled code.