| Date: Thu, 10 Sep 2009 13:03:27 -0500
| From: "Brian Mastenbrook" <[email protected]>
|
| On Thu, 10 Sep 2009 12:45:14 -0500, Andre van Tonder <[email protected]>
| wrote:
|
| > I'm not sure that is the case. At least in R6 Larceny, you can
| > write the portable
| >
| > (import (foo))
| >
| > and let the implementation worry about finding the library for
| > you. In other words, finding the library is not part of the
| > programmer's responsibility. Now, there may be some
| > implementation-specific restrictions on where you may /put/ the
| > library in the file system, and what you may call it, but that is
| > not reflected in any way in the syntax of the portable program,
| > and IMO it is not the place of a spec to really nail this down.
|
| ...
|
| Ultimately the implementation is responsible for reading a
| top-level program and its dependent libraries in some fashion,
| compiling, and executing the result. Unless the
| concatenate-the-world solution is endorsed, they must be separated
| in some fashion in the input. I don't think it's too much to speak
| loosely about directories and files and leave the specifics of how
| that actually works up to the implementation. The result will be
| that implementations sharing a platform will do the same thing
| where the concepts of "directories" and "files" have clear
| definitions, and that your interpretive dancers will have to wear
| placards describing the locations of the libraries they implement.
SLIB solved these problems years ago. The notion of file location is
abstrcted into "vicinities", of which SRFI-59 specifies five:
program-vicinity
library-vicinity
implementation-vicinity
user-vicinity
home-vicinity
The procedure SUB-VICINITY can access sub-directories.
SRFI-59 says:
Vicinities need not be tied to individual files in a file system.
The files named could be members of a zip archive, as Java does.
Vicinities can even be used on flat file systems (which have no
directory structure) by having the vicinity express constraints on
the file name. On most systems a vicinity is a string.
SLIB maps feature names (the argument to REQUIRE) to absolute
pathnames in whatever native filesystem it is running on (unix, FAT,
NTFS, VMS, OSX, ...) using the value of SLIB:CATALOG. Several sources
of catalog information are combined to produce the catalog:
* standard SLIB packages.
* additional packages of interest to this site.
* packages specifically for the variety of Scheme which this session
is running. This catalog, if it exists, is the file `implcat' in
`implementation-invicinity', which is created by loading
`mkimpcat.scm' in `implementation-invicinity' if it exists.
* packages this user wants to always have available. This catalog
is the file `homecat' in the user's "HOME" directory.
* packages germane to working in this (current working) directory.
This catalog is the file `usercat' in the directory to which it
applies. One would typically `cd' to this directory before
starting the Scheme session.
* packages which are part of an application program.
Catalog entries in the later items in the above list take precedence
over the earlier ones.
The creation of implementation-specific part of a catalog
"mkimpcat.scm" can be written in any implementation-specific dialect
of Scheme which can be run by calling:
(load (in-vicinity (implementation-vicinity) "mkimpcat.scm"))
SLIB feature names are symbols. SRFIs are written as hyphenated
symbols: srfi-NN. Symbols are good enough for curated library
collections like SLIB and SRFIs; and also for the local features
registered in "homecat" or "usercat".
Where an extension would be needed is for libraries to be dynamically
fetched from sites on the Internet. URIs have been suggested for
this.
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
