[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:

(library (r6rs)
   (export child-libraries)
   (import)
   (define child-libraries
     '(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.

>  (I
> 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 
Planet.

Anton




More information about the R6RS mailing list