|
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
|
|
2492
|
6 @node Macros, Loading, Functions and Commands, Top
|
|
428
|
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.
|
