Commit | Line | Data |
---|---|---|
73804d4b RS |
1 | @c -*-texinfo-*- |
2 | @c This is part of the GNU Emacs Lisp Reference Manual. | |
3 | @c Copyright (C) 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc. | |
4 | @c See the file elisp.texi for copying conditions. | |
5 | @setfilename ../info/macros | |
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 file that defines | |
167 | them. @xref{Features}. | |
168 | ||
169 | @node Defining Macros | |
170 | @section Defining Macros | |
171 | ||
172 | A Lisp macro is a list whose @sc{car} is @code{macro}. Its @sc{cdr} should | |
173 | be a function; expansion of the macro works by applying the function | |
174 | (with @code{apply}) to the list of unevaluated argument-expressions | |
175 | from the macro call. | |
176 | ||
177 | It is possible to use an anonymous Lisp macro just like an anonymous | |
178 | function, but this is never done, because it does not make sense to pass | |
179 | an anonymous macro to mapping functions such as @code{mapcar}. In | |
180 | practice, all Lisp macros have names, and they are usually defined with | |
181 | the special form @code{defmacro}. | |
182 | ||
183 | @defspec defmacro name argument-list body-forms@dots{} | |
184 | @code{defmacro} defines the symbol @var{name} as a macro that looks | |
185 | like this: | |
186 | ||
187 | @example | |
188 | (macro lambda @var{argument-list} . @var{body-forms}) | |
189 | @end example | |
190 | ||
191 | This macro object is stored in the function cell of @var{name}. The | |
192 | value returned by evaluating the @code{defmacro} form is @var{name}, but | |
193 | usually we ignore this value. | |
194 | ||
195 | The shape and meaning of @var{argument-list} is the same as in a | |
196 | function, and the keywords @code{&rest} and @code{&optional} may be used | |
197 | (@pxref{Argument List}). Macros may have a documentation string, but | |
198 | any @code{interactive} declaration is ignored since macros cannot be | |
199 | called interactively. | |
200 | @end defspec | |
201 | ||
202 | @node Backquote | |
203 | @section Backquote | |
204 | @cindex backquote (list substitution) | |
205 | @cindex ` (list substitution) | |
206 | ||
207 | Macros often need to construct large list structures from a mixture of | |
208 | constants and nonconstant parts. To make this easier, use the macro | |
209 | @code{`} (often called @dfn{backquote}). | |
210 | ||
211 | Backquote allows you to quote a list, but selectively evaluate | |
212 | elements of that list. In the simplest case, it is identical to the | |
213 | special form @code{quote} (@pxref{Quoting}). For example, these | |
214 | two forms yield identical results: | |
215 | ||
216 | @example | |
217 | @group | |
218 | (` (a list of (+ 2 3) elements)) | |
219 | @result{} (a list of (+ 2 3) elements) | |
220 | @end group | |
221 | @group | |
222 | (quote (a list of (+ 2 3) elements)) | |
223 | @result{} (a list of (+ 2 3) elements) | |
224 | @end group | |
225 | @end example | |
226 | ||
f57ddf67 RS |
227 | @findex , @r{(with Backquote)} |
228 | The special marker @code{,} inside of the argument to backquote | |
73804d4b RS |
229 | indicates a value that isn't constant. Backquote evaluates the |
230 | argument of @code{,} and puts the value in the list structure: | |
231 | ||
232 | @example | |
233 | @group | |
234 | (list 'a 'list 'of (+ 2 3) 'elements) | |
235 | @result{} (a list of 5 elements) | |
236 | @end group | |
237 | @group | |
238 | (` (a list of (, (+ 2 3)) elements)) | |
239 | @result{} (a list of 5 elements) | |
240 | @end group | |
241 | @end example | |
242 | ||
f57ddf67 | 243 | @findex ,@@ @r{(with Backquote)} |
73804d4b RS |
244 | @cindex splicing (with backquote) |
245 | You can also @dfn{splice} an evaluated value into the resulting list, | |
246 | using the special marker @code{,@@}. The elements of the spliced list | |
247 | become elements at the same level as the other elements of the resulting | |
248 | list. The equivalent code without using @code{`} is often unreadable. | |
249 | Here are some examples: | |
250 | ||
251 | @example | |
252 | @group | |
253 | (setq some-list '(2 3)) | |
254 | @result{} (2 3) | |
255 | @end group | |
256 | @group | |
257 | (cons 1 (append some-list '(4) some-list)) | |
258 | @result{} (1 2 3 4 2 3) | |
259 | @end group | |
260 | @group | |
261 | (` (1 (,@@ some-list) 4 (,@@ some-list))) | |
262 | @result{} (1 2 3 4 2 3) | |
263 | @end group | |
264 | ||
265 | @group | |
266 | (setq list '(hack foo bar)) | |
267 | @result{} (hack foo bar) | |
268 | @end group | |
269 | @group | |
270 | (cons 'use | |
271 | (cons 'the | |
272 | (cons 'words (append (cdr list) '(as elements))))) | |
273 | @result{} (use the words foo bar as elements) | |
274 | @end group | |
275 | @group | |
276 | (` (use the words (,@@ (cdr list)) as elements)) | |
277 | @result{} (use the words foo bar as elements) | |
278 | @end group | |
279 | @end example | |
280 | ||
f57ddf67 | 281 | Emacs 18 had a bug that made the previous example fail. The bug |
73804d4b RS |
282 | affected @code{,@@} followed only by constant elements. If you are |
283 | concerned with Emacs 18 compatibility, you can work around the bug like | |
284 | this: | |
285 | ||
286 | @example | |
287 | (` (use the words (,@@ (cdr list)) as elements @code{(,@@ nil)})) | |
288 | @end example | |
289 | ||
290 | @noindent | |
291 | @code{(,@@ nil)} avoids the problem by being a nonconstant element that | |
292 | does not affect the result. | |
293 | ||
294 | @defmac ` list | |
295 | This macro quotes @var{list} except for any sublists of the form | |
296 | @code{(, @var{subexp})} or @code{(,@@ @var{listexp})}. Backquote | |
297 | replaces these sublists with the value of @var{subexp} (as a single | |
298 | element) or @var{listexp} (by splicing). Backquote copies the structure | |
299 | of @var{list} down to the places where variable parts are substituted. | |
300 | ||
301 | @ignore @c these work now! | |
302 | There are certain contexts in which @samp{,} would not be recognized and | |
303 | should not be used: | |
304 | ||
305 | @smallexample | |
306 | @group | |
307 | ;; @r{Use of a @samp{,} expression as the @sc{cdr} of a list.} | |
308 | (` (a . (, 1))) ; @r{Not @code{(a . 1)}} | |
309 | @result{} (a \, 1) | |
310 | @end group | |
311 | ||
312 | @group | |
313 | ;; @r{Use of @samp{,} in a vector.} | |
314 | (` [a (, 1) c]) ; @r{Not @code{[a 1 c]}} | |
315 | @error{} Wrong type argument | |
316 | @end group | |
317 | @end smallexample | |
318 | @end ignore | |
319 | @end defmac | |
320 | ||
321 | @cindex CL note---@samp{,}, @samp{,@@} as functions | |
322 | @quotation | |
f57ddf67 RS |
323 | @b{Common Lisp note:} in Common Lisp, @samp{,} and @samp{,@@} are |
324 | implemented as reader macros, so they do not require parentheses. In | |
325 | Emacs Lisp they use function call syntax because reader macros are not | |
326 | supported (for simplicity's sake). | |
73804d4b RS |
327 | @end quotation |
328 | ||
329 | @node Problems with Macros | |
330 | @section Common Problems Using Macros | |
331 | ||
332 | The basic facts of macro expansion have counterintuitive consequences. | |
333 | This section describes some important consequences that can lead to | |
334 | trouble, and rules to follow to avoid trouble. | |
335 | ||
336 | @menu | |
337 | * Argument Evaluation:: The expansion should evaluate each macro arg once. | |
338 | * Surprising Local Vars:: Local variable bindings in the expansion | |
339 | require special care. | |
340 | * Eval During Expansion:: Don't evaluate them; put them in the expansion. | |
341 | * Repeated Expansion:: Avoid depending on how many times expansion is done. | |
342 | @end menu | |
343 | ||
344 | @node Argument Evaluation | |
345 | @subsection Evaluating Macro Arguments Repeatedly | |
346 | ||
347 | When defining a macro you must pay attention to the number of times | |
348 | the arguments will be evaluated when the expansion is executed. The | |
349 | following macro (used to facilitate iteration) illustrates the problem. | |
350 | This macro allows us to write a simple ``for'' loop such as one might | |
351 | find in Pascal. | |
352 | ||
353 | @findex for | |
354 | @smallexample | |
355 | @group | |
356 | (defmacro for (var from init to final do &rest body) | |
357 | "Execute a simple \"for\" loop. | |
358 | For example, (for i from 1 to 10 do (print i))." | |
359 | (list 'let (list (list var init)) | |
360 | (cons 'while (cons (list '<= var final) | |
361 | (append body (list (list 'inc var))))))) | |
362 | @end group | |
363 | @result{} for | |
364 | ||
365 | @group | |
366 | (for i from 1 to 3 do | |
367 | (setq square (* i i)) | |
368 | (princ (format "\n%d %d" i square))) | |
369 | @expansion{} | |
370 | @end group | |
371 | @group | |
372 | (let ((i 1)) | |
373 | (while (<= i 3) | |
374 | (setq square (* i i)) | |
375 | (princ (format "%d %d" i square)) | |
376 | (inc i))) | |
377 | @end group | |
378 | @group | |
379 | ||
380 | @print{}1 1 | |
381 | @print{}2 4 | |
382 | @print{}3 9 | |
383 | @result{} nil | |
384 | @end group | |
385 | @end smallexample | |
386 | ||
387 | @noindent | |
388 | (The arguments @code{from}, @code{to}, and @code{do} in this macro are | |
389 | ``syntactic sugar''; they are entirely ignored. The idea is that you | |
390 | will write noise words (such as @code{from}, @code{to}, and @code{do}) | |
391 | in those positions in the macro call.) | |
392 | ||
f57ddf67 RS |
393 | Here's an equivalent definition simplified through use of backquote: |
394 | ||
395 | @smallexample | |
396 | @group | |
397 | (defmacro for (var from init to final do &rest body) | |
398 | "Execute a simple \"for\" loop. | |
399 | For example, (for i from 1 to 10 do (print i))." | |
400 | (` (let (((, var) (, init))) | |
401 | (while (<= (, var) (, final)) | |
402 | (,@@ body) | |
403 | (inc (, var)))))) | |
404 | @end group | |
405 | @end smallexample | |
406 | ||
407 | Both forms of this definition (with backquote and without) suffer from | |
408 | the defect that @var{final} is evaluated on every iteration. If | |
409 | @var{final} is a constant, this is not a problem. If it is a more | |
410 | complex form, say @code{(long-complex-calculation x)}, this can slow | |
411 | down the execution significantly. If @var{final} has side effects, | |
412 | executing it more than once is probably incorrect. | |
73804d4b RS |
413 | |
414 | @cindex macro argument evaluation | |
415 | A well-designed macro definition takes steps to avoid this problem by | |
416 | producing an expansion that evaluates the argument expressions exactly | |
417 | once unless repeated evaluation is part of the intended purpose of the | |
418 | macro. Here is a correct expansion for the @code{for} macro: | |
419 | ||
420 | @smallexample | |
421 | @group | |
422 | (let ((i 1) | |
423 | (max 3)) | |
424 | (while (<= i max) | |
425 | (setq square (* i i)) | |
426 | (princ (format "%d %d" i square)) | |
427 | (inc i))) | |
428 | @end group | |
429 | @end smallexample | |
430 | ||
431 | Here is a macro definition that creates this expansion: | |
432 | ||
433 | @smallexample | |
434 | @group | |
435 | (defmacro for (var from init to final do &rest body) | |
436 | "Execute a simple for loop: (for i from 1 to 10 do (print i))." | |
437 | (` (let (((, var) (, init)) | |
438 | (max (, final))) | |
439 | (while (<= (, var) max) | |
440 | (,@@ body) | |
441 | (inc (, var)))))) | |
442 | @end group | |
443 | @end smallexample | |
444 | ||
445 | Unfortunately, this introduces another problem. | |
446 | @ifinfo | |
447 | Proceed to the following node. | |
448 | @end ifinfo | |
449 | ||
450 | @node Surprising Local Vars | |
451 | @subsection Local Variables in Macro Expansions | |
452 | ||
453 | @ifinfo | |
454 | In the previous section, the definition of @code{for} was fixed as | |
455 | follows to make the expansion evaluate the macro arguments the proper | |
456 | number of times: | |
457 | ||
458 | @smallexample | |
459 | @group | |
460 | (defmacro for (var from init to final do &rest body) | |
461 | "Execute a simple for loop: (for i from 1 to 10 do (print i))." | |
462 | @end group | |
463 | @group | |
464 | (` (let (((, var) (, init)) | |
465 | (max (, final))) | |
466 | (while (<= (, var) max) | |
467 | (,@@ body) | |
468 | (inc (, var)))))) | |
469 | @end group | |
470 | @end smallexample | |
471 | @end ifinfo | |
472 | ||
473 | The new definition of @code{for} has a new problem: it introduces a | |
474 | local variable named @code{max} which the user does not expect. This | |
475 | causes trouble in examples such as the following: | |
476 | ||
477 | @example | |
478 | @group | |
479 | (let ((max 0)) | |
480 | (for x from 0 to 10 do | |
481 | (let ((this (frob x))) | |
482 | (if (< max this) | |
483 | (setq max this))))) | |
484 | @end group | |
485 | @end example | |
486 | ||
487 | @noindent | |
488 | The references to @code{max} inside the body of the @code{for}, which | |
489 | are supposed to refer to the user's binding of @code{max}, really access | |
490 | the binding made by @code{for}. | |
491 | ||
492 | The way to correct this is to use an uninterned symbol instead of | |
493 | @code{max} (@pxref{Creating Symbols}). The uninterned symbol can be | |
f57ddf67 RS |
494 | bound and referred to just like any other symbol, but since it is |
495 | created by @code{for}, we know that it cannot already appear in the | |
496 | user's program. Since it is not interned, there is no way the user can | |
497 | put it into the program later. It will never appear anywhere except | |
498 | where put by @code{for}. Here is a definition of @code{for} that works | |
499 | this way: | |
73804d4b RS |
500 | |
501 | @smallexample | |
502 | @group | |
503 | (defmacro for (var from init to final do &rest body) | |
504 | "Execute a simple for loop: (for i from 1 to 10 do (print i))." | |
505 | (let ((tempvar (make-symbol "max"))) | |
506 | (` (let (((, var) (, init)) | |
507 | ((, tempvar) (, final))) | |
508 | (while (<= (, var) (, tempvar)) | |
509 | (,@@ body) | |
510 | (inc (, var))))))) | |
511 | @end group | |
512 | @end smallexample | |
513 | ||
514 | @noindent | |
515 | This creates an uninterned symbol named @code{max} and puts it in the | |
516 | expansion instead of the usual interned symbol @code{max} that appears | |
517 | in expressions ordinarily. | |
518 | ||
519 | @node Eval During Expansion | |
520 | @subsection Evaluating Macro Arguments in Expansion | |
521 | ||
522 | Another problem can happen if you evaluate any of the macro argument | |
523 | expressions during the computation of the expansion, such as by calling | |
524 | @code{eval} (@pxref{Eval}). If the argument is supposed to refer to the | |
525 | user's variables, you may have trouble if the user happens to use a | |
526 | variable with the same name as one of the macro arguments. Inside the | |
527 | macro body, the macro argument binding is the most local binding of this | |
528 | variable, so any references inside the form being evaluated do refer | |
529 | to it. Here is an example: | |
530 | ||
531 | @example | |
532 | @group | |
533 | (defmacro foo (a) | |
534 | (list 'setq (eval a) t)) | |
535 | @result{} foo | |
536 | @end group | |
537 | @group | |
538 | (setq x 'b) | |
539 | (foo x) @expansion{} (setq b t) | |
540 | @result{} t ; @r{and @code{b} has been set.} | |
541 | ;; @r{but} | |
542 | (setq a 'c) | |
543 | (foo a) @expansion{} (setq a t) | |
544 | @result{} t ; @r{but this set @code{a}, not @code{c}.} | |
545 | ||
546 | @end group | |
547 | @end example | |
548 | ||
549 | It makes a difference whether the user's variable is named @code{a} or | |
550 | @code{x}, because @code{a} conflicts with the macro argument variable | |
551 | @code{a}. | |
552 | ||
553 | Another reason not to call @code{eval} in a macro definition is that | |
554 | it probably won't do what you intend in a compiled program. The | |
555 | byte-compiler runs macro definitions while compiling the program, when | |
556 | the program's own computations (which you might have wished to access | |
557 | with @code{eval}) don't occur and its local variable bindings don't | |
558 | exist. | |
559 | ||
560 | The safe way to work with the run-time value of an expression is to | |
561 | put the expression into the macro expansion, so that its value is | |
562 | computed as part of executing the expansion. | |
563 | ||
564 | @node Repeated Expansion | |
565 | @subsection How Many Times is the Macro Expanded? | |
566 | ||
567 | Occasionally problems result from the fact that a macro call is | |
568 | expanded each time it is evaluated in an interpreted function, but is | |
569 | expanded only once (during compilation) for a compiled function. If the | |
570 | macro definition has side effects, they will work differently depending | |
571 | on how many times the macro is expanded. | |
572 | ||
573 | In particular, constructing objects is a kind of side effect. If the | |
574 | macro is called once, then the objects are constructed only once. In | |
575 | other words, the same structure of objects is used each time the macro | |
576 | call is executed. In interpreted operation, the macro is reexpanded | |
577 | each time, producing a fresh collection of objects each time. Usually | |
578 | this does not matter---the objects have the same contents whether they | |
579 | are shared or not. But if the surrounding program does side effects | |
580 | on the objects, it makes a difference whether they are shared. Here is | |
581 | an example: | |
582 | ||
583 | @lisp | |
584 | @group | |
585 | (defmacro empty-object () | |
586 | (list 'quote (cons nil nil))) | |
587 | @end group | |
588 | ||
589 | @group | |
590 | (defun initialize (condition) | |
591 | (let ((object (empty-object))) | |
592 | (if condition | |
593 | (setcar object condition)) | |
594 | object)) | |
595 | @end group | |
596 | @end lisp | |
597 | ||
598 | @noindent | |
599 | If @code{initialize} is interpreted, a new list @code{(nil)} is | |
600 | constructed each time @code{initialize} is called. Thus, no side effect | |
601 | survives between calls. If @code{initialize} is compiled, then the | |
602 | macro @code{empty-object} is expanded during compilation, producing a | |
603 | single ``constant'' @code{(nil)} that is reused and altered each time | |
604 | @code{initialize} is called. | |
605 | ||
606 | One way to avoid pathological cases like this is to think of | |
607 | @code{empty-object} as a funny kind of constant, not as a memory | |
608 | allocation construct. You wouldn't use @code{setcar} on a constant such | |
609 | as @code{'(nil)}, so naturally you won't use it on @code{(empty-object)} | |
610 | either. |