428
+ − 1 @c -*-texinfo-*-
+ − 2 @c This is part of the XEmacs Lisp Reference Manual.
444
+ − 3 @c Copyright (C) 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc.
428
+ − 4 @c See the file lispref.texi for copying conditions.
+ − 5 @setfilename ../../info/macros.info
+ − 6 @node Macros, Loading, Functions, Top
+ − 7 @chapter Macros
+ − 8 @cindex macros
+ − 9
+ − 10 @dfn{Macros} enable you to define new control constructs and other
+ − 11 language features. A macro is defined much like a function, but instead
+ − 12 of telling how to compute a value, it tells how to compute another Lisp
+ − 13 expression which will in turn compute the value. We call this
+ − 14 expression the @dfn{expansion} of the macro.
+ − 15
+ − 16 Macros can do this because they operate on the unevaluated expressions
+ − 17 for the arguments, not on the argument values as functions do. They can
+ − 18 therefore construct an expansion containing these argument expressions
+ − 19 or parts of them.
+ − 20
+ − 21 If you are using a macro to do something an ordinary function could
+ − 22 do, just for the sake of speed, consider using an inline function
+ − 23 instead. @xref{Inline Functions}.
+ − 24
+ − 25 @menu
+ − 26 * Simple Macro:: A basic example.
+ − 27 * Expansion:: How, when and why macros are expanded.
+ − 28 * Compiling Macros:: How macros are expanded by the compiler.
+ − 29 * Defining Macros:: How to write a macro definition.
+ − 30 * Backquote:: Easier construction of list structure.
+ − 31 * Problems with Macros:: Don't evaluate the macro arguments too many times.
+ − 32 Don't hide the user's variables.
+ − 33 @end menu
+ − 34
+ − 35 @node Simple Macro
+ − 36 @section A Simple Example of a Macro
+ − 37
+ − 38 Suppose we would like to define a Lisp construct to increment a
+ − 39 variable value, much like the @code{++} operator in C. We would like to
+ − 40 write @code{(inc x)} and have the effect of @code{(setq x (1+ x))}.
+ − 41 Here's a macro definition that does the job:
+ − 42
+ − 43 @findex inc
+ − 44 @example
+ − 45 @group
+ − 46 (defmacro inc (var)
+ − 47 (list 'setq var (list '1+ var)))
+ − 48 @end group
+ − 49 @end example
+ − 50
+ − 51 When this is called with @code{(inc x)}, the argument @code{var} has
+ − 52 the value @code{x}---@emph{not} the @emph{value} of @code{x}. The body
+ − 53 of the macro uses this to construct the expansion, which is @code{(setq
+ − 54 x (1+ x))}. Once the macro definition returns this expansion, Lisp
+ − 55 proceeds to evaluate it, thus incrementing @code{x}.
+ − 56
+ − 57 @node Expansion
+ − 58 @section Expansion of a Macro Call
+ − 59 @cindex expansion of macros
+ − 60 @cindex macro call
+ − 61
+ − 62 A macro call looks just like a function call in that it is a list which
+ − 63 starts with the name of the macro. The rest of the elements of the list
+ − 64 are the arguments of the macro.
+ − 65
+ − 66 Evaluation of the macro call begins like evaluation of a function call
+ − 67 except for one crucial difference: the macro arguments are the actual
+ − 68 expressions appearing in the macro call. They are not evaluated before
+ − 69 they are given to the macro definition. By contrast, the arguments of a
+ − 70 function are results of evaluating the elements of the function call
+ − 71 list.
+ − 72
+ − 73 Having obtained the arguments, Lisp invokes the macro definition just
+ − 74 as a function is invoked. The argument variables of the macro are bound
+ − 75 to the argument values from the macro call, or to a list of them in the
+ − 76 case of a @code{&rest} argument. And the macro body executes and
+ − 77 returns its value just as a function body does.
+ − 78
+ − 79 The second crucial difference between macros and functions is that the
+ − 80 value returned by the macro body is not the value of the macro call.
+ − 81 Instead, it is an alternate expression for computing that value, also
+ − 82 known as the @dfn{expansion} of the macro. The Lisp interpreter
+ − 83 proceeds to evaluate the expansion as soon as it comes back from the
+ − 84 macro.
+ − 85
+ − 86 Since the expansion is evaluated in the normal manner, it may contain
+ − 87 calls to other macros. It may even be a call to the same macro, though
+ − 88 this is unusual.
+ − 89
+ − 90 You can see the expansion of a given macro call by calling
+ − 91 @code{macroexpand}.
+ − 92
+ − 93 @defun macroexpand form &optional environment
+ − 94 @cindex macro expansion
+ − 95 This function expands @var{form}, if it is a macro call. If the result
+ − 96 is another macro call, it is expanded in turn, until something which is
+ − 97 not a macro call results. That is the value returned by
+ − 98 @code{macroexpand}. If @var{form} is not a macro call to begin with, it
+ − 99 is returned as given.
+ − 100
+ − 101 Note that @code{macroexpand} does not look at the subexpressions of
+ − 102 @var{form} (although some macro definitions may do so). Even if they
+ − 103 are macro calls themselves, @code{macroexpand} does not expand them.
+ − 104
+ − 105 The function @code{macroexpand} does not expand calls to inline functions.
+ − 106 Normally there is no need for that, since a call to an inline function is
+ − 107 no harder to understand than a call to an ordinary function.
+ − 108
+ − 109 If @var{environment} is provided, it specifies an alist of macro
+ − 110 definitions that shadow the currently defined macros. Byte compilation
+ − 111 uses this feature.
+ − 112
+ − 113 @smallexample
+ − 114 @group
+ − 115 (defmacro inc (var)
+ − 116 (list 'setq var (list '1+ var)))
+ − 117 @result{} inc
+ − 118 @end group
+ − 119
+ − 120 @group
+ − 121 (macroexpand '(inc r))
+ − 122 @result{} (setq r (1+ r))
+ − 123 @end group
+ − 124
+ − 125 @group
+ − 126 (defmacro inc2 (var1 var2)
+ − 127 (list 'progn (list 'inc var1) (list 'inc var2)))
+ − 128 @result{} inc2
+ − 129 @end group
+ − 130
+ − 131 @group
+ − 132 (macroexpand '(inc2 r s))
+ − 133 @result{} (progn (inc r) (inc s)) ; @r{@code{inc} not expanded here.}
+ − 134 @end group
+ − 135 @end smallexample
+ − 136 @end defun
+ − 137
+ − 138 @node Compiling Macros
+ − 139 @section Macros and Byte Compilation
+ − 140 @cindex byte-compiling macros
+ − 141
+ − 142 You might ask why we take the trouble to compute an expansion for a
+ − 143 macro and then evaluate the expansion. Why not have the macro body
+ − 144 produce the desired results directly? The reason has to do with
+ − 145 compilation.
+ − 146
+ − 147 When a macro call appears in a Lisp program being compiled, the Lisp
+ − 148 compiler calls the macro definition just as the interpreter would, and
+ − 149 receives an expansion. But instead of evaluating this expansion, it
+ − 150 compiles the expansion as if it had appeared directly in the program.
+ − 151 As a result, the compiled code produces the value and side effects
+ − 152 intended for the macro, but executes at full compiled speed. This would
+ − 153 not work if the macro body computed the value and side effects
+ − 154 itself---they would be computed at compile time, which is not useful.
+ − 155
+ − 156 In order for compilation of macro calls to work, the macros must be
+ − 157 defined in Lisp when the calls to them are compiled. The compiler has a
+ − 158 special feature to help you do this: if a file being compiled contains a
+ − 159 @code{defmacro} form, the macro is defined temporarily for the rest of
+ − 160 the compilation of that file. To use this feature, you must define the
+ − 161 macro in the same file where it is used and before its first use.
+ − 162
+ − 163 Byte-compiling a file executes any @code{require} calls at top-level
+ − 164 in the file. This is in case the file needs the required packages for
+ − 165 proper compilation. One way to ensure that necessary macro definitions
+ − 166 are available during compilation is to require the files that define
+ − 167 them (@pxref{Named Features}). To avoid loading the macro definition files
+ − 168 when someone @emph{runs} the compiled program, write
+ − 169 @code{eval-when-compile} around the @code{require} calls (@pxref{Eval
+ − 170 During Compile}).
+ − 171
+ − 172 @node Defining Macros
+ − 173 @section Defining Macros
+ − 174
+ − 175 A Lisp macro is a list whose @sc{car} is @code{macro}. Its @sc{cdr} should
+ − 176 be a function; expansion of the macro works by applying the function
+ − 177 (with @code{apply}) to the list of unevaluated argument-expressions
+ − 178 from the macro call.
+ − 179
+ − 180 It is possible to use an anonymous Lisp macro just like an anonymous
+ − 181 function, but this is never done, because it does not make sense to pass
+ − 182 an anonymous macro to functionals such as @code{mapcar}. In practice,
+ − 183 all Lisp macros have names, and they are usually defined with the
+ − 184 special form @code{defmacro}.
+ − 185
+ − 186 @defspec defmacro name argument-list body-forms@dots{}
+ − 187 @code{defmacro} defines the symbol @var{name} as a macro that looks
+ − 188 like this:
+ − 189
+ − 190 @example
+ − 191 (macro lambda @var{argument-list} . @var{body-forms})
+ − 192 @end example
+ − 193
+ − 194 This macro object is stored in the function cell of @var{name}. The
+ − 195 value returned by evaluating the @code{defmacro} form is @var{name}, but
+ − 196 usually we ignore this value.
+ − 197
+ − 198 The shape and meaning of @var{argument-list} is the same as in a
+ − 199 function, and the keywords @code{&rest} and @code{&optional} may be used
+ − 200 (@pxref{Argument List}). Macros may have a documentation string, but
+ − 201 any @code{interactive} declaration is ignored since macros cannot be
+ − 202 called interactively.
+ − 203 @end defspec
+ − 204
+ − 205 @node Backquote
+ − 206 @section Backquote
+ − 207 @cindex backquote (list substitution)
+ − 208 @cindex ` (list substitution)
+ − 209 @findex `
+ − 210
+ − 211 Macros often need to construct large list structures from a mixture of
+ − 212 constants and nonconstant parts. To make this easier, use the macro
+ − 213 @samp{`} (often called @dfn{backquote}).
+ − 214
+ − 215 Backquote allows you to quote a list, but selectively evaluate
+ − 216 elements of that list. In the simplest case, it is identical to the
+ − 217 special form @code{quote} (@pxref{Quoting}). For example, these
+ − 218 two forms yield identical results:
+ − 219
+ − 220 @example
+ − 221 @group
+ − 222 `(a list of (+ 2 3) elements)
+ − 223 @result{} (a list of (+ 2 3) elements)
+ − 224 @end group
+ − 225 @group
+ − 226 '(a list of (+ 2 3) elements)
+ − 227 @result{} (a list of (+ 2 3) elements)
+ − 228 @end group
+ − 229 @end example
+ − 230
+ − 231 @findex , @r{(with Backquote)}
+ − 232 The special marker @samp{,} inside of the argument to backquote
+ − 233 indicates a value that isn't constant. Backquote evaluates the
+ − 234 argument of @samp{,} and puts the value in the list structure:
+ − 235
+ − 236 @example
+ − 237 @group
+ − 238 (list 'a 'list 'of (+ 2 3) 'elements)
+ − 239 @result{} (a list of 5 elements)
+ − 240 @end group
+ − 241 @group
+ − 242 `(a list of ,(+ 2 3) elements)
+ − 243 @result{} (a list of 5 elements)
+ − 244 @end group
+ − 245 @end example
+ − 246
+ − 247 @findex ,@@ @r{(with Backquote)}
+ − 248 @cindex splicing (with backquote)
+ − 249 You can also @dfn{splice} an evaluated value into the resulting list,
+ − 250 using the special marker @samp{,@@}. The elements of the spliced list
+ − 251 become elements at the same level as the other elements of the resulting
+ − 252 list. The equivalent code without using @samp{`} is often unreadable.
+ − 253 Here are some examples:
+ − 254
+ − 255 @example
+ − 256 @group
+ − 257 (setq some-list '(2 3))
+ − 258 @result{} (2 3)
+ − 259 @end group
+ − 260 @group
+ − 261 (cons 1 (append some-list '(4) some-list))
+ − 262 @result{} (1 2 3 4 2 3)
+ − 263 @end group
+ − 264 @group
+ − 265 `(1 ,@@some-list 4 ,@@some-list)
+ − 266 @result{} (1 2 3 4 2 3)
+ − 267 @end group
+ − 268
+ − 269 @group
+ − 270 (setq list '(hack foo bar))
+ − 271 @result{} (hack foo bar)
+ − 272 @end group
+ − 273 @group
+ − 274 (cons 'use
+ − 275 (cons 'the
+ − 276 (cons 'words (append (cdr list) '(as elements)))))
+ − 277 @result{} (use the words foo bar as elements)
+ − 278 @end group
+ − 279 @group
+ − 280 `(use the words ,@@(cdr list) as elements)
+ − 281 @result{} (use the words foo bar as elements)
+ − 282 @end group
+ − 283 @end example
+ − 284
444
+ − 285 @quotation
428
+ − 286 In older versions of Emacs (before XEmacs 19.12 or FSF Emacs version
+ − 287 19.29), @samp{`} used a different syntax which required an extra level
+ − 288 of parentheses around the entire backquote construct. Likewise, each
+ − 289 @samp{,} or @samp{,@@} substitution required an extra level of
+ − 290 parentheses surrounding both the @samp{,} or @samp{,@@} and the
+ − 291 following expression. The old syntax required whitespace between the
+ − 292 @samp{`}, @samp{,} or @samp{,@@} and the following expression.
+ − 293
+ − 294 This syntax is still accepted, but no longer recommended except for
+ − 295 compatibility with old Emacs versions.
+ − 296 @end quotation
+ − 297
+ − 298 @node Problems with Macros
+ − 299 @section Common Problems Using Macros
+ − 300
+ − 301 The basic facts of macro expansion have counterintuitive consequences.
+ − 302 This section describes some important consequences that can lead to
+ − 303 trouble, and rules to follow to avoid trouble.
+ − 304
+ − 305 @menu
+ − 306 * Argument Evaluation:: The expansion should evaluate each macro arg once.
+ − 307 * Surprising Local Vars:: Local variable bindings in the expansion
+ − 308 require special care.
+ − 309 * Eval During Expansion:: Don't evaluate them; put them in the expansion.
+ − 310 * Repeated Expansion:: Avoid depending on how many times expansion is done.
+ − 311 @end menu
+ − 312
+ − 313 @node Argument Evaluation
+ − 314 @subsection Evaluating Macro Arguments Repeatedly
+ − 315
+ − 316 When defining a macro you must pay attention to the number of times
+ − 317 the arguments will be evaluated when the expansion is executed. The
+ − 318 following macro (used to facilitate iteration) illustrates the problem.
+ − 319 This macro allows us to write a simple ``for'' loop such as one might
+ − 320 find in Pascal.
+ − 321
+ − 322 @findex for
+ − 323 @smallexample
+ − 324 @group
+ − 325 (defmacro for (var from init to final do &rest body)
+ − 326 "Execute a simple \"for\" loop.
+ − 327 For example, (for i from 1 to 10 do (print i))."
+ − 328 (list 'let (list (list var init))
+ − 329 (cons 'while (cons (list '<= var final)
+ − 330 (append body (list (list 'inc var)))))))
+ − 331 @end group
+ − 332 @result{} for
+ − 333
+ − 334 @group
+ − 335 (for i from 1 to 3 do
+ − 336 (setq square (* i i))
+ − 337 (princ (format "\n%d %d" i square)))
+ − 338 @expansion{}
+ − 339 @end group
+ − 340 @group
+ − 341 (let ((i 1))
+ − 342 (while (<= i 3)
+ − 343 (setq square (* i i))
+ − 344 (princ (format "%d %d" i square))
+ − 345 (inc i)))
+ − 346 @end group
+ − 347 @group
+ − 348
+ − 349 @print{}1 1
+ − 350 @print{}2 4
+ − 351 @print{}3 9
+ − 352 @result{} nil
+ − 353 @end group
+ − 354 @end smallexample
+ − 355
+ − 356 @noindent
+ − 357 (The arguments @code{from}, @code{to}, and @code{do} in this macro are
+ − 358 ``syntactic sugar''; they are entirely ignored. The idea is that you
+ − 359 will write noise words (such as @code{from}, @code{to}, and @code{do})
+ − 360 in those positions in the macro call.)
+ − 361
+ − 362 Here's an equivalent definition simplified through use of backquote:
+ − 363
+ − 364 @smallexample
+ − 365 @group
+ − 366 (defmacro for (var from init to final do &rest body)
+ − 367 "Execute a simple \"for\" loop.
+ − 368 For example, (for i from 1 to 10 do (print i))."
+ − 369 `(let ((,var ,init))
+ − 370 (while (<= ,var ,final)
+ − 371 ,@@body
+ − 372 (inc ,var))))
+ − 373 @end group
+ − 374 @end smallexample
+ − 375
+ − 376 Both forms of this definition (with backquote and without) suffer from
+ − 377 the defect that @var{final} is evaluated on every iteration. If
+ − 378 @var{final} is a constant, this is not a problem. If it is a more
+ − 379 complex form, say @code{(long-complex-calculation x)}, this can slow
+ − 380 down the execution significantly. If @var{final} has side effects,
+ − 381 executing it more than once is probably incorrect.
+ − 382
+ − 383 @cindex macro argument evaluation
+ − 384 A well-designed macro definition takes steps to avoid this problem by
+ − 385 producing an expansion that evaluates the argument expressions exactly
+ − 386 once unless repeated evaluation is part of the intended purpose of the
+ − 387 macro. Here is a correct expansion for the @code{for} macro:
+ − 388
+ − 389 @smallexample
+ − 390 @group
+ − 391 (let ((i 1)
+ − 392 (max 3))
+ − 393 (while (<= i max)
+ − 394 (setq square (* i i))
+ − 395 (princ (format "%d %d" i square))
+ − 396 (inc i)))
+ − 397 @end group
+ − 398 @end smallexample
+ − 399
444
+ − 400 Here is a macro definition that creates this expansion:
428
+ − 401
+ − 402 @smallexample
+ − 403 @group
+ − 404 (defmacro for (var from init to final do &rest body)
+ − 405 "Execute a simple for loop: (for i from 1 to 10 do (print i))."
+ − 406 `(let ((,var ,init)
+ − 407 (max ,final))
+ − 408 (while (<= ,var max)
+ − 409 ,@@body
+ − 410 (inc ,var))))
+ − 411 @end group
+ − 412 @end smallexample
+ − 413
+ − 414 Unfortunately, this introduces another problem.
+ − 415 @ifinfo
+ − 416 Proceed to the following node.
+ − 417 @end ifinfo
+ − 418
+ − 419 @node Surprising Local Vars
+ − 420 @subsection Local Variables in Macro Expansions
+ − 421
+ − 422 @ifinfo
+ − 423 In the previous section, the definition of @code{for} was fixed as
+ − 424 follows to make the expansion evaluate the macro arguments the proper
+ − 425 number of times:
+ − 426
+ − 427 @smallexample
+ − 428 @group
+ − 429 (defmacro for (var from init to final do &rest body)
+ − 430 "Execute a simple for loop: (for i from 1 to 10 do (print i))."
+ − 431 @end group
+ − 432 @group
+ − 433 `(let ((,var ,init)
+ − 434 (max ,final))
+ − 435 (while (<= ,var max)
+ − 436 ,@@body
+ − 437 (inc ,var))))
+ − 438 @end group
+ − 439 @end smallexample
+ − 440 @end ifinfo
+ − 441
+ − 442 The new definition of @code{for} has a new problem: it introduces a
+ − 443 local variable named @code{max} which the user does not expect. This
+ − 444 causes trouble in examples such as the following:
+ − 445
+ − 446 @smallexample
+ − 447 @group
+ − 448 (let ((max 0))
+ − 449 (for x from 0 to 10 do
+ − 450 (let ((this (frob x)))
+ − 451 (if (< max this)
+ − 452 (setq max this)))))
+ − 453 @end group
+ − 454 @end smallexample
+ − 455
+ − 456 @noindent
+ − 457 The references to @code{max} inside the body of the @code{for}, which
+ − 458 are supposed to refer to the user's binding of @code{max}, really access
+ − 459 the binding made by @code{for}.
+ − 460
+ − 461 The way to correct this is to use an uninterned symbol instead of
+ − 462 @code{max} (@pxref{Creating Symbols}). The uninterned symbol can be
+ − 463 bound and referred to just like any other symbol, but since it is
+ − 464 created by @code{for}, we know that it cannot already appear in the
+ − 465 user's program. Since it is not interned, there is no way the user can
+ − 466 put it into the program later. It will never appear anywhere except
+ − 467 where put by @code{for}. Here is a definition of @code{for} that works
+ − 468 this way:
+ − 469
+ − 470 @smallexample
+ − 471 @group
+ − 472 (defmacro for (var from init to final do &rest body)
+ − 473 "Execute a simple for loop: (for i from 1 to 10 do (print i))."
+ − 474 (let ((tempvar (make-symbol "max")))
+ − 475 `(let ((,var ,init)
+ − 476 (,tempvar ,final))
+ − 477 (while (<= ,var ,tempvar)
+ − 478 ,@@body
+ − 479 (inc ,var)))))
+ − 480 @end group
+ − 481 @end smallexample
+ − 482
+ − 483 @noindent
+ − 484 This creates an uninterned symbol named @code{max} and puts it in the
+ − 485 expansion instead of the usual interned symbol @code{max} that appears
+ − 486 in expressions ordinarily.
+ − 487
+ − 488 @node Eval During Expansion
+ − 489 @subsection Evaluating Macro Arguments in Expansion
+ − 490
+ − 491 Another problem can happen if you evaluate any of the macro argument
+ − 492 expressions during the computation of the expansion, such as by calling
+ − 493 @code{eval} (@pxref{Eval}). If the argument is supposed to refer to the
+ − 494 user's variables, you may have trouble if the user happens to use a
+ − 495 variable with the same name as one of the macro arguments. Inside the
+ − 496 macro body, the macro argument binding is the most local binding of this
+ − 497 variable, so any references inside the form being evaluated do refer
+ − 498 to it. Here is an example:
+ − 499
+ − 500 @example
+ − 501 @group
+ − 502 (defmacro foo (a)
+ − 503 (list 'setq (eval a) t))
+ − 504 @result{} foo
+ − 505 @end group
+ − 506 @group
+ − 507 (setq x 'b)
+ − 508 (foo x) @expansion{} (setq b t)
+ − 509 @result{} t ; @r{and @code{b} has been set.}
+ − 510 ;; @r{but}
+ − 511 (setq a 'c)
+ − 512 (foo a) @expansion{} (setq a t)
+ − 513 @result{} t ; @r{but this set @code{a}, not @code{c}.}
+ − 514
+ − 515 @end group
+ − 516 @end example
+ − 517
+ − 518 It makes a difference whether the user's variable is named @code{a} or
+ − 519 @code{x}, because @code{a} conflicts with the macro argument variable
+ − 520 @code{a}.
+ − 521
+ − 522 Another reason not to call @code{eval} in a macro definition is that
+ − 523 it probably won't do what you intend in a compiled program. The
+ − 524 byte-compiler runs macro definitions while compiling the program, when
+ − 525 the program's own computations (which you might have wished to access
+ − 526 with @code{eval}) don't occur and its local variable bindings don't
+ − 527 exist.
+ − 528
+ − 529 The safe way to work with the run-time value of an expression is to
+ − 530 put the expression into the macro expansion, so that its value is
+ − 531 computed as part of executing the expansion.
+ − 532
+ − 533 @node Repeated Expansion
+ − 534 @subsection How Many Times is the Macro Expanded?
+ − 535
+ − 536 Occasionally problems result from the fact that a macro call is
+ − 537 expanded each time it is evaluated in an interpreted function, but is
+ − 538 expanded only once (during compilation) for a compiled function. If the
+ − 539 macro definition has side effects, they will work differently depending
+ − 540 on how many times the macro is expanded.
+ − 541
+ − 542 In particular, constructing objects is a kind of side effect. If the
+ − 543 macro is called once, then the objects are constructed only once. In
+ − 544 other words, the same structure of objects is used each time the macro
+ − 545 call is executed. In interpreted operation, the macro is reexpanded
+ − 546 each time, producing a fresh collection of objects each time. Usually
+ − 547 this does not matter---the objects have the same contents whether they
+ − 548 are shared or not. But if the surrounding program does side effects
+ − 549 on the objects, it makes a difference whether they are shared. Here is
+ − 550 an example:
+ − 551
+ − 552 @lisp
+ − 553 @group
+ − 554 (defmacro empty-object ()
+ − 555 (list 'quote (cons nil nil)))
+ − 556 @end group
+ − 557
+ − 558 @group
+ − 559 (defun initialize (condition)
+ − 560 (let ((object (empty-object)))
+ − 561 (if condition
+ − 562 (setcar object condition))
+ − 563 object))
+ − 564 @end group
+ − 565 @end lisp
+ − 566
+ − 567 @noindent
+ − 568 If @code{initialize} is interpreted, a new list @code{(nil)} is
+ − 569 constructed each time @code{initialize} is called. Thus, no side effect
+ − 570 survives between calls. If @code{initialize} is compiled, then the
+ − 571 macro @code{empty-object} is expanded during compilation, producing a
+ − 572 single ``constant'' @code{(nil)} that is reused and altered each time
+ − 573 @code{initialize} is called.
+ − 574
+ − 575 One way to avoid pathological cases like this is to think of
+ − 576 @code{empty-object} as a funny kind of constant, not as a memory
+ − 577 allocation construct. You wouldn't use @code{setcar} on a constant such
+ − 578 as @code{'(nil)}, so naturally you won't use it on @code{(empty-object)}
+ − 579 either.