This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.
On 12/13/05, bear <bear@xxxxxxxxx> 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...)