[Chicken-hackers] Using a container module to export bindings from a group of related modules

[Tony Sidaway]

Usually in modular development of extension libraries you arrive at a
situation where, while it makes sense to develop the library as a
series of separate modules, from the point of view of most users all
the bindings provided by a number of modules have to be used together.
 It's then quite common for the extension library developer to provide
a convenience or container module which simply loads and exports all
public bindings from a number of modules.  The user can then gain
access to all the bindings he needs for his task by a simple "use"
with a single module as its target.

See the locale module in the locale egg for an example of this: it
imports and exports public bindings from  the modules locale-timezone,
locale-builtin, locale-posix, locale-components, locale-categories and
locale-current.  The chicken programmer simply types "(use locale)"
and the container module "locale" takes care of loading and exposing
bindings for those modules.

To do this using the current export syntax the extension developer
must exhaustively enumerate all exports from each module.  Doing this
manually has obvious drawbacks--the list of exports in the container
module could easily get out of step with the list of exports in each
separate module.

The container module could easily be constructed by a simple script,
of course.  The script would read the export forms in a number of
chicken module source files and then write a module listing the
bindings in its own export form and listing the modules in its import
form.

It seems to me that, instead, we could probably make it easier for the
extension library developer by allowing some syntax in the export form
that means "export all public bindings from this named module".  If
that were permitted, of course, it would not be strictly necessary to
specify the modules in question in the import form, because the import
would be implicit.  In effect. this form of export implies a
(require-extension ...) for each module whose public bindings are to
be exported.

Something simple like

(export ... (module IDENTIFIER...) ...)

In the locale example, the extension library developer would then
write his locale module, in its entirety, as:

(module locale
(export (module locale-timezone locale-builtin locale-posix
locale-components locale-categories locale-current)
(import chicken scheme)
)

If renaming, prefixes, exceptions, etc, are desired, these could be
specified in a matching import clause in the container module,
otherwise a straightforword import should be assumed.