[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Definition time macros
- To: firstname.lastname@example.org (Robert Kessler)
- Subject: Definition time macros
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Tue, 15 Jul 1986 14:36:00 -0000
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: Msg of 14 Jul 1986 22:32-EDT from kessler%utah-orion at utah-cs.arpa (Robert Kessler)
- Sender: FAHLMAN@C.CS.CMU.EDU
I also believe in the CL goal of the exact same semantics between the
compiler and interpreter. Its hard enough teaching students Lisp when you
also have to discuss the grungy details of the differences between compiled
and interpreted code. However, one big hole in the CL scheme is that it
is not specified that all macros must expand at definition time. That is the
only way that one can force the same semantics.
1) Does CL say anything that forbids a system from expanding macros at
function definition time?
This is legal, I think. Since the book explicitly gives permission to
compile code on sight instead of having a real interpreter, it must
follow that defun-time expansion of macros is legal. H-P currently does
this, as I'm sure you know.
2) Would it be reasonable to add this requirement to the standard?
In my opinion, it should not even be encouraged, let alone required.
I've been discussing the desirabilty of doing DEFUN-time expansion and
other source-level transforms with some of the H-P people since I
started using their system. In my view, the only reason to have an
interpreter around at all is that it is much easier to debug code if it
is still more or less what you wrote. Once the proverbial clever
compiler has come in and changed everything beyond recognition, you may
as well let it go ahead and finish compiling. Just doing the expansions
and source-level transforms gets you the worst of both worlds: the code
is unreadable, but not fast.
Before someone points it out, I know that with a couple of man-years of
work, one can develop a memoizing system and matching debugging tools so
that the compiler's alterations become invisible to the user most of the
time, but these things never quite get the job done right, in my
So it is a desirable goal to have interpreted code exactly match
compiled code, but it is also a desirable goal to have a good
source-language debugging environment in the interpreter. It's a
trade-off. In my experience, the differences introduced by expanding
macros at execution time, rather than definition time, are not
troublesome in practice and are not the kind of thing that a beginner is
going to run into. (Actually, that statement assumes that the compiler
does macro-expansion and then code generation in the same recursive
descent. If all of the source-level transforms are done in a pre-pass,
as H-P likes to do, you can get some more glaring discrepancies, and
defun-time expansion looks a bit more important.)