[R6RS] Library hierarchy & wildcard imports
Anton van Straaten
anton at appsolutions.com
Thu Aug 24 10:34:41 EDT 2006
Michael Sperber wrote:
> Would the wildcard work only for the r6rs libraries? In general, this
> appears to be sensitive to what libraries are available in the system,
> which may change over time, making the whole thing quite fragile.
A "parent" library could be required to statically define all its
children, to make the hierarchy a property of the library's definition.
Conceptually, something like this:
'(core syntax data arithmetic i/o records sugar)))
Something like this ought to allow non-R6RS libraries to support wildcards.
This could also allow the R6RS version feature to be used to ensure that
you know what libraries you're getting when using a wildcard.
> have to admit that I don't know how Java deals with the problem.)
The solution I've just described would be less fragile than Java's. In
Java, the classes pulled in by a wildcard import can change from one
compile to the next - it's simply based on what the Java compiler finds
in the "class path", and isn't specified anywhere in the source code
(other than by the presence of the relevant source files).
(For typical Java implementations, those same compiled classes have to
be available in the classpath at runtime, but I think that's beyond
anything that the R6RS needs to worry about).
> PS: I really like your sugar library!
:-) I did think that was one minor benefit of the proposal: that it
provides a natural way to import all optional sugar with a single import.
For similar reasons, given a larger set of libraries, I think the
wildcard approach would become more useful. It could help deal with
related SRFIs, and with portable library repositories similar to PLT's
More information about the R6RS