[ < ] | [ > ] | [ << ] | [Plus haut] | [ >> ] | [Top] | [Table des matières] | [Index] | [ ? ] |
You might ask why we take the trouble to compute an expansion for a macro and then evaluate the expansion. Why not have the macro body produce the desired results directly? The reason has to do with compilation.
When a macro call appears in a Lisp program being compiled, the Lisp compiler calls the macro definition just as the interpreter would, and receives an expansion. But instead of evaluating this expansion, it compiles the expansion as if it had appeared directly in the program. As a result, the compiled code produces the value and side effects intended for the macro, but executes at full compiled speed. This would not work if the macro body computed the value and side effects itself—they would be computed at compile time, which is not useful.
In order for compilation of macro calls to work, the macros must already be
defined in Lisp when the calls to them are compiled. The compiler has a
special feature to help you do this: if a file being compiled contains a
defmacro
form, the macro is defined temporarily for the rest of the
compilation of that file. To make this feature work, you must put the
defmacro
in the same file where it is used, and before its first use.
Byte-compiling a file executes any require
calls at top-level in the
file. This is in case the file needs the required packages for proper
compilation. One way to ensure that necessary macro definitions are
available during compilation is to require the files that define them
(voir la section Features). To avoid loading the macro definition files when
someone runs the compiled program, write eval-when-compile
around the require
calls (voir la section Evaluation During Compilation).
[ < ] | [ > ] | [ << ] | [Plus haut] | [ >> ] | [Top] | [Table des matières] | [Index] | [ ? ] |
Ce document a été généré par Eric Reinbold le 13 Octobre 2007 en utilisant texi2html 1.78.