[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Scheme-reports] searching for libraries
- To: scheme-reports <scheme-reports@x>
- Subject: [Scheme-reports] searching for libraries
- From: Per Bothner <per@x>
- Date: Tue, 31 Jan 2012 23:45:09 -0800
5.5.1 Library Syntax says:
"Note: Implementations are encouraged to search for files in
the directory which contains the including file, and to provide
a way for users to specify other directories to search."
What does this mean? This implies a mapping from library to file,
which I don't see otherwise specified.
Of course without such a mapping, libraries aren't very portable ...
Can there be multiple libraries in a source file? That might
make for easier interchange/distribution, but it makes searching
difficult, unless a collection of libraries are pre-processed
(or compiled) into a data-base or index. Which is certainly
a possible model.
I know standards dislike taking about how code is mapped to files,
but for "small Scheme" it would be helpful to have at least a
non-normative addendum. I think there are two plausible models
- and it is possible to non-normatively bless both:
(1) A "library interchange file" is the concatenation of one or
more libraries. An installation provides a command to install
one or more interchange files into a repository, where repository
has some location (typically a directory). When a program
(top-level) is evaluated, it search one or more repositories,
in some implementation-dependent way. Note this model assumes
some installation step, which can be combined with compilation.
(2) A library file contains a single library. A library named
(A1 A2 AN) is in a file named "A1/A2/AN.scm" (or some other
standardized file extension), relative to some
"library root" (repository). For portability, library component
names should be integers or lower-case identifiers that avoid
certain prohibited characters. When a library or top-level
imports some other library, the corresponding file is found
in the obvious way. This model does not require indexing
or compilation, though it does not preclude either.
Model (2) is familiar from C/C++ (cpp), Java, and more.
It is well-tested, flexible, compatible with compilation,
and immediate evaluation. It does work test with a
standardized file extension.
I suggest an addendum that would recommend (but not require)
that implementations provide at least (2), but may also
recommend supporting (1).
Scheme-reports mailing list