Date: Sun, 04 Dec 2005 09:51:14 +0100
   From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>

   Taylor Campbell <xxxxxx@mumble.net> writes:

   > It does, though, make it difficult to extend in the current syntax
   > in a way that bear wants.  Grovelling through the source to
   > libraries is not an option, but currently the EXPORT syntax is
   > embedded in the library bodies.

   But in a way that's trivial to extract.

Trivial in the sense that it's placed at the head of a library's body,
but to extract that you would have to open the file the library is
defined in, read the whole library form, and then quickly scan the
head of the form form for the EXPORT form.  This is probably not
satisfactory for bear's scenario, where there might be thousands or
hundreds of thousands of modules, and reading every library's body for
every time it is used in another library is simply not an option.  The
only way I can think of to get around this would be to kludge together
a provisional reader to extract the EXPORT form and nothing else, but
this is a poor, inflexible workaround for a problem that needn't be
necessary in the first place.

   Yes; I worded this very poorly.  What I meant is that you need access
   to the implementation of modules you import in many cases anyway; the
   (implied) interface is not enough.

Right, but the dependency graph, in general, is dramatically
diminished if restricted to macros, and this diminution is probably
critical for bear's scenario.  Anyway, I suspect that the specified
interface is enough for the majority of cases.