On 12/13/05, bear <xxxxxx@sonic.net> wrote:
> The problem is, that tight a binding presents problems for truly
> separate compilation.  Inter-module macrology is *THE* barrier,
> IMO, to truly large lispy-language systems because it makes it
> necessary to have all source visible to compile any source.

Is that true?  I thought that compiling some module A could yield a
compiled form of both its phase zero code and its phase one code, and
that compiling a module B that imports A only requires loading and
running the compiled form of A's phase one code.  I don't see why you
would need A's source code after A has been compiled, even to compile
B.  You need its macro transformers, and they need to run in the state
produced by evaluating its top-level phase one forms.  But not its
source.

But, sticking to the larger question of inter-module macrology
preventing separate compilation, in one way or another:

It's true that, if you export any macros, you lose the ability to pass
off every module to a separate worker for independent compilation.
The task of compiling the whole program becomes partially serialized.
But not unduly so, it seems to me.  That is, unless you have wildly
undisciplined macro exportation and importation going on (the rough
equivalent of, in a C program, putting all your declarations in one
header file and then #including that header into every .c file), there
will still be a reasonable level of parallelism possible.  You have to
compile all a modules' imports before you can compile a module, but
unless your import DAG is a total ordering, you can do something in
parallel.

I have the sense that these dependencies are something intrinsic in
the form of the program you're trying to build, and that in languages
that allow static forward declarations of the sort you're talking
about, the same work is just being smooshed around somewhere else,
like a lump in a carpet.  (But this time too, I'm too tired to see how
to give that intuition some teeth...)