Subject: Re: Macrology and automated invocation of defclass?
From: (Rob Warnock)
Date: Sun, 22 Jul 2007 20:14:26 -0500
Newsgroups: comp.lang.lisp
Message-ID: <>
Daniel Trstenjak  <> wrote:
| Pascal Costanza wrote:
| > No, that's not the general idiom. A good macro is designed in such a
| > way that there is an underlying functional abstraction to which the
| > macro expands which is also part of the official API. This allows you
| > to use the functional abstraction in your own macro expansions
| > (or even as part of your regular code).
| I can see the advantage of the functional abstraction when the
| implementation of the macro has to be changed, no need for
| recompling the code which uses the macro...

Actually, this is *NOT* true!! You still need to recompile the code
to get the effect of any changes in the functional abstraction behind
the macro, since the macro (and hence the function behind it) is only
called during the macro-expansion phase of compilation, and is *not*
called at runtime! See the following for the official verbiage: Minimal Compilation

Also note that while the macro function is forbidden to modify its
argument form in any way [and thus so-called "displacing" macroexpansion
is forbidden]: Macro Forms

many implementations (CMUCL, CLISP, most others) get around that for
performance reasons by actually doing at least Minimal Compilation
of even "interpreted" code [REPL & LOADed source], so even there
changing the function behind a macro will require re-evaluating any
defining forms [DEFUN, DEFVAR, etc.] whose values contained a call
of that macro. Example:

    > (defmacro foo () 12)

    > (defun bar () (foo))

    > (compiled-function-p 'bar)

    NIL      ; Note: This would be T in SBCL
    > (bar)

    > (defmacro foo () 17)

    > (bar)

    12	     ; But 17 is also legal (albeit an inefficient implementation)

| ... are there other ones?

Yes. [Pascal answered this in his parallel reply.]


Rob Warnock			<>
627 26th Avenue			<URL:>
San Mateo, CA 94403		(650)572-2607