Date: Sat, 03 Dec 2005 14:33:34 +0100
   From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>

   But anyway, your concern is a very valid one.  Here's what I think we
   came down on:

   - The current proposal doesn't preclude a future extension for
     optionally specifying more static information about the names being
     exported, as is possible, for instance, in Scheme 48 or Bigloo.

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.  My proposal, and Scheme48's module system, would make
such an extension even easier and in a satisfactory way for the
conditions bear would like.

   - Any such extension is bound to provide only incomplete static
     information about the thing being exported, and thus preclude
     certain kinds of optimization.

   - A type language (or flow language or whatever) would be a topic for
     active research, which I don't think we were prepared to do.

   - Consequently, highly optimizing compilers (like Chez Scheme, for
     example) really need to look at the entire source code of the
     everything you're importing (or some representation thereof) to do a
     good job.

This is true for heavily optimizing compilers, but I don't think bear
was referring to them, particularly since (in response to the first
point) all compilers that do not perform whole program analysis lose
information anyway.  Knowing exactly what identifiers have run-time
variable denotations and what identifiers have syntactic denotations
is enough to know how to compile the code (see below on how to deal
with macros).  Actually, the current SRFI doesn't even provide enough
information for that, but my alternative proposal & Scheme48's module
system both do.  Moreover, separation of interface from implementation
would allow interfaces to include specifications of properties that
implementations must support, if such flow languages were developed.

   - Macros require you to have some representation of the source code of
     the library you're importing anyway.  (Some people might argue this
     is a design mistake in the library syntax---several people are
     working on macro/module systems that don't have this property.  But
     once again, (very) active ongoing research, not ready for R6RS.)

This is true (except I don't see why you need the source code and not
just any representation of the code, source or compiled), but bear's
situation and requirements are still useful for all of the cases where
macros are not used; macros would only imply points of synchronization
in the distributed compilation where the compilation of one module
would simply wait until another module, from which the first imported
syntax, finishes, to access the macros from it.