Subject: Re: Macrology and automated invocation of defclass?
From: (Rob Warnock)
Date: Tue, 31 Jul 2007 04:12:30 -0500
Newsgroups: comp.lang.lisp
Message-ID: <>
Barry Margolin  <> wrote:
| (Rob Warnock) wrote:
| > 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: ...
| It depends on how the macro is written.  It's possible to design some 
| macros so that they simply expand into a call to a function, and that 
| function can be redefined at run time.
| I remember that many macros in the Symbolics table and presentation 
| system were written something like this:
| (defmacro with-table ((stream &rest options) &body body)
|   `(with-table-internal
|      #'(lambda (,stream) ,@body)
|      ,@options))
| The macro is so trivial that it virtually never needs to be redefined.  
| All the real work takes place in the function WITH-TABLE-INTERNAL, which 
| can be redefined on the fly.

Sure, many "WITH"-style macros are of this style, and I've written
plenty of those myself. One set in particular was for wrapping a
"container" HTML web page around some locally-specified content.
E.g., a call to:

    (with-normal-results-page (title)
      ...[some HTOUT or CL-WHO code]...)

expanded into:

    (normal-results-page (http-request-stream *http-request*)
			 (http-request-self *http-request*)
			 (lambda (s)
			   (with-html-output (s s t)
			     ...[some HTOUT or CL-WHO code]...)))

Clearly one could change the layout of the header/footer/sidebars of
such pages by redefining the NORMAL-RESULTS-PAGE *without* recompling
ot reloading any code containing uses of WITH-NORMAL-RESULTS-PAGE.
So my comment [to which you replied] was overly general. Mea culpa.

But I was mainly trying to warn about those macros that do source
code *rewriting*, for which the "underlying function" is the rewriting
algorithm itself, and which are usually of the form:

    (defmacro my-macro (macro-args...)
      (my-expansion-function macro-args...))

or possibly with some very simple rearranging of the MACRO-ARGS before
calling the expansion function.

Those macros do indeed require that any binding forms calling them
be recompiled [or, for those interpreters that always do at least
ANSI CL "minimal compilation", reloaded] when the expansion function
is redefined.


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