[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Using Macros in Lisp
- To: Vincent Keunen <email@example.com.BE>
- Subject: RE: Using Macros in Lisp
- From: Kevin Gallagher <Gallagher@gilgamesh.cs.umass.edu>
- Date: Fri, 8 Mar 91 12:10:10 EST
- Cc: firstname.lastname@example.org
- In-reply-to: <19910307135315.8.KEUNEN@milou.nrb.be>
- Reply-to: Gallagher@gilgamesh.cs.umass.edu
- Sender: Gallagher@Gilgamesh
From: Vincent Keunen <email@example.com.BE>
From: Kevin Gallagher <Gallagher@gilgamesh.cs.umass.edu>
I think a contributing factor to the misunderstanding of macros is the
way they are described in many lisp texts (including "AI Programming",
2nd edition). For example, "Macros are a special type of Lisp function.
They differ from the others in that they go through not one but two
rounds of evaluation."
This starts people off with the misconception that macros are functions.
They are not functions, they are a source code transformation mechanism.
Right. But unlike most other macro mechanisms in other languages, the
macro mechanism in lisp isn't a simple text substitution. It is
actually a lisp program that is evaluated at compile time to generate
the final source that will be evaluated.
Yes -- this is what makes lisp macros more powerful and flexible than
(say) C macros.
That's why lots of people talk about "double evaluation", which is not wrong.
No, it's not wrong, but it emphasizes the wrong thing, and it obscures
the fact that *only* the *result* of the ``first evaluation'' is
significant. Any side effects will (or may) be lost.
The notion of double evaluation comes from a time when most lisp
programs were interpreted, and the compiler was seen as a somewhat
cumbersome and untrustworthy facility. Because you would develop and
debug your programs in the interpreter, you didn't see any difference
between the semantics of macro expansion (the first evaluation) and
executing the expanded form (the second evaluation). This hid the fact
that the semantics of the two evaluations were different until you
(shudder) compiled your program.
(In fact, many people didn't compile their programs exactly because of
this and other incompatibilities between compiled and interpreted code.
Addressing this problem was one of the important contributions of Common