首页 > 代码库 > Lecture Notes: Macros

Lecture Notes: Macros

2024-08-03 00:09:27   216人阅读

原论文链接失效，特在这里保存一份

http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html

Lisp functions take Lisp values as input and return Lisp values. They are executed at run-time. Lisp macros take Lisp code as input, and return Lisp code. They are executed at compiler pre-processor time, just like in C. The resultant code gets executed at run-time. Almost all the errors that result from using macros can be traced to a misunderstanding of this fact.

1. Basic Idea: Macros take unevaluated Lisp code and return a Lisp form. This form should be code that calculates the proper value. Example:

(defmacro Square (X) 
  ‘(* ,X ,X))

This means that wherever the pre-processor sees (Square XXX) to replaces it with (* XXX XXX). The resultant code is what the compiler sees.

2. Debugging technique: macroexpand-1

When designing a function, you can type a call to the function into the Lisp Listener (prompt), and see if it returns the correct value. However, when you type a macro "call" into the Lisp Listener, two things happen: first, the macro is expanded into its resultant code, and then that code is evaluated. It is more useful during debugging to be able to examine the results of these two steps individually. The functionmacroexpand-1 returns the result of stage one of this process:

(macroexpand-1 ‘(Square 9)) ==> (* 9 9)

"If in doubt, macroexpand-1 it out."

3. Purpose: To control evaluation of the arguments.

Since macros are so much harder to use than functions, a good rule of thumb is:don‘t use defmacro if defun will work fine. So, for example, there would be no reason to try to use a macro forSquare: a function would be much easier to write and test. In Lisp, unlike in C, there is no need to use macros to avoid the very small runtime overhead of a function call: there is a separate method for that (the "inline" proclamation) that lets you do this without switching to a different syntax. What macros can do that functions cannot is to control when the arguments get evaluated. Functions evaluate all of their arguments before entering the body of the function. Macros don‘t evaluate any of their arguments at preprocessor time unless you tell it to, so it can expand into code that might not evaluate all of the arguments. For example, suppose thatcond was in the language, but if wasn‘t, and you wanted to write a version ofif using cond.

(defun Iff-Wrong (Test Then &optional Else)
  (cond
    (Test Then)
    (t    Else)))

The problem with this is that it always evaluates all of its arguments, while the semantics ofif dictate that exactly one of the Then and Else arguments gets evaluated. For example:

(let ((Test ‘A))
  (Iff-Wrong (numberp Test)
             (sqrt Test)
             "Sorry, SQRT only defined for numbers"))

will crash, since it tries to take (sqrt ‘A).A correct version, with behavior identical to the built-inif (except that the real if only has one required arg, not two), would be:

(defmacro Iff (Test Then &optional Else)
  "A replacement for IF, takes 2 or 3 arguments. If the first evaluates to
  non-NIL, evaluate and return the second. Otherwise evaluate and return
  the third (which defaults to NIL)"
  ‘(cond
     (,Test ,Then)
     (t     ,Else)) )

A similar example would be NAND ("Not AND"), which returns true if at least one of the arguments is false, but, like the built-inand, does "short-circuit evaluation" whereby once it has the answer it returns immediately without evaluating later arguments.

(defmacro Nand (&rest Args)
  ‘(not (and ,@Args)))
4. Bugs:

    • (A) Trying to evaluate arguments at run-time

    • (B) Evaluating arguments too many times

    • (C) Variable name clashes.

      (A) Trying to evaluate arguments at run-time

Macros are expanded at compiler pre-processor time. Thus, the values of the arguments are generally not available, and code that tries to make use of them will not work. I.e. consider the following definition ofSquare, which tries to replace (Square 4) with 16 instead of with(* 4 4).

(defmacro Square (X)
  (* X X))
This would indeed work for (Square 4), but would crash for (Square X), sinceX is probably a variable whose value is not known until run-time. Since macros do sometimes make use of variables and functions at expansion time, and to simplify debugging in general,it is strongly recommended that all macro definitions and any variables and functions that they use at expansion time (as opposed to code they actually expand into) be placed in a separate file that is loaded before any files containing code that makes use of the macros.

      (B) Evaluating arguments too many times

Let‘s take another look at our first definition of the Square macro.

(defmacro Square (X) ‘(* ,X ,X))

This looks OK on first blush. However, try macroexpand-1‘ing a form, and you notice that it evaluates its arguments twice:

(macroexpand-1 ‘(Square (Foo 2))) ==> (* (Foo 2) (Foo 2))
Foo gets called twice, but it should only be called once. Not only is this inefficient, but could return the wrong value ifFoo does not always return the same value. I.e. consider Next-Integer, which returns 1 the first time called, then 2, then 3.(Square (Next-Integer)) would return N*(N+1), not N2, plus would advance N by 2. Similarly,(Square (random 10)) would not necessarily generate a perfect square! With Lisp you have the full power of the language available at preprocessor time (unlike in C), so you can use ordinary Lisp constructs to solve this problem. In this case,let can be used to store the result in a local variable to prevent multiple evaluation. There is no general solution to this type of problem in C.

(defmacro Square2 (X)
  ‘(let ((Temp ,X))
     (* Temp Temp)))

(macroexpand-1 ‘(Square2 (Foo 2)))
==> (let ((Temp (Foo 2)))
         (* Temp Temp))
This is what we want.

      (C) Variable name clashes.
When using let to suppress multiple evaluation, one needs to be sure that there is no conflict between the local variable chosen and any existing variable names. The above version ofSquare2 is perfectly safe, but consider instead the following macro, which takes two numbers and squares the sum of them:
(defmacro Square-Sum (X Y)
  ‘(let* ((First ,X)
          (Second ,Y)
          (Sum (+ First Second)))
     (* Sum Sum)) )


This looks pretty good, even after macroexpansion:
(macroexpand-1 ‘(Square-Sum 3 4))
==> (LET* ((FIRST 3)
          (SECOND 4)
          (SUM (+ FIRST SECOND)))
     (* SUM SUM))


which gives the proper result. However, this version has a subtle problem. The local variables we chose would conflict with existing local variable names if a variable namedFirst already existed. E.g.
(macroexpand-1 ‘(Square-Sum 1 First)) 
==> (LET* ((FIRST 1)
          (SECOND FIRST)
          (SUM (+ FIRST SECOND)))
     (* SUM SUM))

The problem here is that (SECOND FIRST) gets the value of the newlocal variable FIRST, not the one you passed in. Thus
(let ((First 9)) (Square-Sum 1 First)) 


returns 4, not 100! Solutions to this type of problem are quite complicated, and involve usinggensym to generate a local variable name that is guaranteed to be unique.
Moral: even seemingly simple macros are hard to get right, so don‘t use macros unless they really add something. BothSquare and Square-Sum are inappropriate uses of macros.
(defmacro Square-Sum2 (X Y)
  (let ((First (gensym "FIRST-"))
        (Second (gensym "SECOND-"))
        (Sum (gensym "SUM-")))
    ‘(let* ((,First ,X)
            (,Second ,Y)
            (,Sum (+ ,First ,Second)))
       (* ,Sum ,Sum))
))


Now
(macroexpand-1 ‘(Square-Sum2 1 First))
==> (LET* ((#:FIRST-590 1)
          (#:SECOND-591 FIRST)
          (#:SUM-592 (+ #:FIRST-590 #:SECOND-591)))
     (* #:SUM-592 #:SUM-592))


This expansion has no dependence on any local variable names in the macro definition itself, and since the generated ones are guaranteed to be unique, is safe from name collisions.
Lecture Notes: Macros






























        

            
                
                  
                
                

                    联系

                    我们