More thoughts on load time/compile time

[Drew McDermott <Mcdermott at YALE>]

(1) On a practical note, I went ahead and implemented a hack for delaying
macro expansion.  Basically, we define DE so that
   (DE sym (-args-) -body-)
expands, not into
   (DEFINE (sym -args-) -body-)
but into
   (DEFINE (sym -args-)
     (DELAY-MACROS 'sym (LIST -args-) '(LAMBDA (-args-) -body-)))

DELAY-MACROS then actually defines sym, and applies it to the list of
args.  The new definition, with macros expanded, wipes this one out.

Complications: A. This must interact properly with the data-driven
programming scheme described in <A.MCDERMOTT.ALPHA>DDT.TXT.
B. The given definition is completely unsuitable for compile time.
So we must use the original scheme when it is known that the function is
to be compiled.  (As before, a two-pass compiler is needed.)

This scheme appears to work.  I will report later on how much it speeds
up loading.  Currently, DELAY-MACROS causes a burst of [Redefining ...]
and [Assigning ...] messages.  I rather appreciate these, since they
tell me what's taking so long, but I'm sure there is some way to turn
them off.

(2) In reaction to Jonathan's remarks, e.g.:

              ...  I'm not sure just what it is that you're doing
              that really requires the use of macros; why won't
              procedure integration do what you want?  I presume
              that :  is a readmacro; what does it expand into?
              Are you saying that most of the work is done at
              macro-expansion time, and little is done at
              run-time?

This made me stop and think a bit, but not too  much.  Basically, I
thought pretty hard about all these issues when I started transporting
NISP to T.  My thought processes have generally led me to stick with
old-fashioned techniques in many cases.  At first I felt bad about
this, but I got over it.

I am not sure what to say about the clash between T-thought and
Lisp-thought.  In many cases, I side with T in principle, with Lisp in
practice.  Again and again, old-fashioned Lisp turns out to do the
right thing for the wrong reason, or no reason at all.  A case in point
is the layer of indirection and delay that you get from the confusion
between functions and their names.  Anyone can see that the people who
designed things this way had no clear idea of what they were doing
(one hopes), and that this is the first thing to change in a "reasonable"
dialect.  On the other hand, look at the inconvenience from doing things
the right way!

Another example is compile time vs. interpret time, and the relation of
this issue to questions like whether files are to be known to Lisp.
The answer on elegance grounds is clearly "no," but what a nice abstraction
file transduction is for a portable Lisp dialect.  Every operating
system has files, for one thing.  For another, it is absolutely clear
when compilation is occurring and what it is operating on.  Letting
DE know when compilation is occurring is a relatively straightforward
matter.

Perhaps we need a support group (FEXPRs Anonymous?) I can turn to in
moments like these to be talked back into the sobriety of Lexical Oneness.
-------