[R6RS] Library hierarchy & wildcard imports

[Anton van Straaten]

Here's my proposal for a wildcard import feature for 
hierarchically-organized libraries.

Overview & Rationale
--------------------
The structure of R6RS library names already implicitly supports a 
hierarchy of libraries.  This can be exploited for some of the R6RS 
standard libraries, giving library names such as:

   (r6rs arithmetic fixnum)
   (r6rs i/o simple)

This could be taken a step further by allowing library imports to 
specify a set of libraries using a partial library name, so that for 
example:

   (import (r6rs records *))

...would import a set of all libraries whose name begins with "r6rs 
records" (i.e. the four record libraries 'procedural', 'explicit', 
'implicit', and 'inspection').

[In addition, it could be useful to support a list of libraries in the 
terminal position of a library name specification, so that e.g.:

   (import (r6rs records (explicit procedural)))

...would import the two specified record libraries, 'explicit' and 
'procedural', without having to repeat their fully-qualified names.]

Supporting this wildcard import feature would provide some additional 
benefits for library organization:

* It would support improved library granularity, while still allowing 
related sets of libraries to be loaded with few import clauses.

* The set of libraries identified by '(r6rs)' would naturally meet the 
requirement for an import that contains most or all of the libraries 
defined by the R6RS.

* The library hierarchy could be structured and documented in the most 
appropriate way, without imposing excessive granularity on import 
specifications in actual programs.

* For non-standard applications which require unusual combinations of 
libraries, improved library granularity would allow small libraries to 
be additively imported, rather than requiring the import of a large base 
library in conjunction with many exclusions of individual identifiers.


Proposed hierarchy
------------------
The following proposes two library hierarchies, named 'r6rs' and 
'r6rs-aux'.  The latter exists solely to provide a place outside of the 
'r6rs' library tree, for libraries such as 'mutable-pairs', 'eval', and 
'r5rs-compatibility'.  This means that (import (r6rs)) will not include 
the latter libraries.

The composition of the 'r6rs' hierarchy is based on the current set of 
libraries specified by the core/library split proposal, but organized 
more explicitly into a hierarchy.  In particular, a 'base' library 
branch, which in turn contains a 'core' branch, is used to allow the 
base library to address the various competing requirements that have 
been encountered.

The specific contents of both the 'base' and 'core' branches still need 
to be discussed, of course.  In particular, 'core' could be a single 
library, as opposed to a collection of libraries.  However, the intent 
is that the 'core' hierarchy could correspond closely to the 
documentation of core R6RS features, without affecting the usability of 
the overall hierarchy in actual programs.  This may reduce the pressure 
which Mike has been exerting on 'base' to be smaller and thus possibly 
less useful in real programs.

The proposed hierarchies are as follows:

r6rs -+-- base -+-- core -+-- language  (lambda, if, quote, set!, defns)
       |         |         +-- sugar     (binding, conditionals...)
       |         |         +-- library   (other core procedures)
       |         |         +-- control   (call/cc, dynamic-wind)
       |         |         +-- values    (values, call-with-values)
       |         |         +-- error     (error, contract-violation)
       |         +-- syntax-rules
       |         +-- arithmetic --- generic
       |         +-- bytes
       |         +-- i/o --- port
       |         +-- records -+-- procedural
       |                      +-- explicit
       +-- syntax-case
       +-- data -+-- lists
       |         +-- hash
       |         +-- conditions
       |         +-- unicode
       |         +-- promises
       +-- arithmetic -+-- fixnum
       |               +-- flonum
       |               +-- fx
       |               +-- exact
       |               +-- inexact
       +-- i/o -+-- primitive
       |        +-- simple
       +-- records -+-- implicit
       |            +-- inspection
       +-- sugar -+-- when-unless
                  +-- case-lambda
                  +-- do         ; for Will; otherwise in (core sugar)

r6rs-aux -+-- mutable-pairs
           +-- eval
           +-- r5rs-compatibility

Importing (r6rs base *) should then give a useful base language, while 
importing (r6rs *) would give most of R6RS.


Issue & Alternative
-------------------
One issue above is that because of the contents of the base library, 
some related libraries are found in two different parts of the 
hierarchy: port i/o, generic arithmetic, and the base record libraries 
in particular are under 'base', but more naturally belong under 'r6rs 
i/o', 'r6rs arithmetic', and 'r6rs records' respectively.

One way that this could be addressed would be to move those libraries to 
where they more naturally belong, and go back to the approach of 
providing a separate 'r6rs-base' library, which would essentially be a 
view of a subset of the main hierarchy.  In that case, the main 
hierarchy would become somewhat cleaner:

r6rs -+-- core -+-- language  (lambda, if, quote, set!, defns)
       |         +-- sugar     (binding, conditionals...)
       |         +-- library   (other core procedures)
       |         +-- control   (call/cc, dynamic-wind)
       |         +-- values    (values, call-with-values)
       |         +-- error     (error, contract-violation)
       +-- syntax -+-- rules
       |           +-- case
       +-- data -+-- lists
       |         +-- bytes
       |         +-- hash
       |         +-- conditions
       |         +-- unicode
       |         +-- promises
       +-- arithmetic -+-- generic
       |               +-- fixnum
       |               +-- flonum
       |               +-- fx
       |               +-- exact
       |               +-- inexact
       +-- i/o -+-- primitive
       |        +-- port
       |        +-- simple
       +-- records -+-- procedural
       |            +-- explicit
       |            +-- implicit
       |            +-- inspection
       +-- sugar -+-- when-unless
                  +-- case-lambda
                  +-- do

...and 'r6rs-base' would simply be a top-level library outside the above 
hierarchy, which would combine all the desired component libraries.

Anton