From 82ba818ff456bcd6d56a06226e3f27e98fbb55c3 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Thu, 14 Aug 2025 22:58:58 -0500 Subject: removing all downloaded devdocs files --- devdocs/elisp/repeated-expansion.html | 16 ---------------- 1 file changed, 16 deletions(-) delete mode 100644 devdocs/elisp/repeated-expansion.html (limited to 'devdocs/elisp/repeated-expansion.html') diff --git a/devdocs/elisp/repeated-expansion.html b/devdocs/elisp/repeated-expansion.html deleted file mode 100644 index da3f82d7..00000000 --- a/devdocs/elisp/repeated-expansion.html +++ /dev/null @@ -1,16 +0,0 @@ -

How Many Times is the Macro Expanded?

Occasionally problems result from the fact that a macro call is expanded each time it is evaluated in an interpreted function, but is expanded only once (during compilation) for a compiled function. If the macro definition has side effects, they will work differently depending on how many times the macro is expanded.

Therefore, you should avoid side effects in computation of the macro expansion, unless you really know what you are doing.

One special kind of side effect can’t be avoided: constructing Lisp objects. Almost all macro expansions include constructed lists; that is the whole point of most macros. This is usually safe; there is just one case where you must be careful: when the object you construct is part of a quoted constant in the macro expansion.

If the macro is expanded just once, in compilation, then the object is constructed just once, during compilation. But in interpreted execution, the macro is expanded each time the macro call runs, and this means a new object is constructed each time.

In most clean Lisp code, this difference won’t matter. It can matter only if you perform side-effects on the objects constructed by the macro definition. Thus, to avoid trouble, avoid side effects on objects constructed by macro definitions. Here is an example of how such side effects can get you into trouble: 

(defmacro empty-object ()
-  (list 'quote (cons nil nil)))
-
- -
(defun initialize (condition)
-  (let ((object (empty-object)))
-    (if condition
-        (setcar object condition))
-    object))
-
-

If initialize is interpreted, a new list (nil) is constructed each time initialize is called. Thus, no side effect survives between calls. If initialize is compiled, then the macro empty-object is expanded during compilation, producing a single constant (nil) that is reused and altered each time initialize is called.

One way to avoid pathological cases like this is to think of empty-object as a funny kind of constant, not as a memory allocation construct. You wouldn’t use setcar on a constant such as '(nil), so naturally you won’t use it on (empty-object) either.

-

- Copyright © 1990-1996, 1998-2022 Free Software Foundation, Inc.
Licensed under the GNU GPL license.
- https://www.gnu.org/software/emacs/manual/html_node/elisp/Repeated-Expansion.html -

-
-- cgit v1.2.3