;;; -*- Mode:gate; Fonts:(HL12 HL12I HL12B CPTFONTB HL12BI HL12B HL12I ) -*- =Node: Introduction to Macros =Text: 3INTRODUCTION TO MACROS* If 2eval* is handed a list whose car is a symbol, then 2eval* inspects the definition of the symbol to find out what to do. If the definition is a cons, and the car of the cons is the symbol 2macro*, then the definition (i.e. that cons) is called a 1macro*. The cdr of the cons should be a function of two arguments. 2eval* applies the function to the form it was originally given, takes whatever is returned, and evaluates that in lieu of the original form. Here is a simple example. Suppose the definition of the symbol 2first* is 3(macro lambda (x ignore) * 3 (list 'car (cadr x)))* This thing is a macro: it is a cons whose car is the symbol 2macro*. What happens if we try to evaluate a form 2(first '(a b c))*? Well, 2eval* sees that it has a list whose car is a symbol (namely, 2first*), so it looks at the definition of the symbol and sees that it is a cons whose car is 2macro*; the definition is a macro. 2eval* takes the cdr of the cons, which is supposed to be the macro's 1expander function*, and calls it providing as arguments the original form that 2eval* was handed, and an environment data structure that this macro does not use. So it calls 2(lambda (x ignore) (list 'car (cadr x)))* and the first argument is 2(first '(a b c))*. Whatever this returns is the 1expansion* of the macro call. It will be evaluated in place of the original form. In this case, 2x* is bound to 2(first '(a b c))*, 2(cadr x)* evaluates to 2'(a b c)*, and 2(list 'car (cadr x))* evaluates to 2(car '(a b c))*, which is the expansion. 2eval* now evaluates the expansion. 2(car '(a b c))* returns 2a*, and so the result is that 2(first '(a b c))* returns 2a*. What have we done? We have defined a macro called 2first*. What the macro does is to 1translate* the form to some other form. Our translation is very simple--it just translates forms that look like 2(first 1x*)* into 2(car 1x*)*, for any form 1x*. We can do much more interesting things with macros, but first we show how to define a macro. 3macro* 1Special Form* The primitive special form for defining macros is 2macro*. A macro definition looks like this: 3(macro 1name* (1form-arg* 1env-arg*)* 3 1body*)* 1name* can be any function spec. 1form-arg* and 1env-arg* must be variables. 1body* is a sequence of Lisp forms that expand the macro; the last form should return the expansion. To define our 2first* macro, we would say 3(macro first (x ignore)* 3 (list 'car (cadr x)))* Only sophisticated macros need to use value passed for the 1env-arg*; this one does not need it, so the argument variable 2ignore* is used for it. See 4(MACROS-1)Defmacro* for information on it. Here are some more simple examples of macros. Suppose we want any form that looks like 2(addone 1x*)* to be translated into 2(plus 1 1x*)*. To define a macro to do this we would say 3(macro addone (x ignore)* 3 (list 'plus '1 (cadr x)))* Now say we wanted a macro which would translate 2(increment 1x*)* into 2(setq 1x* (1+ 1x*)*. This would be: 3(macro increment (x ignore)* 3 (list 'setq (cadr x) (list '1+ (cadr x))))* Of course, this macro is of limited usefulness. The reason is that the form in the cadr of the 2increment* form had better be a symbol. If you tried 2(increment (car x))*, it would be translated into 2(setq (car x) (1+ (car x)))*, and 2setq* would complain. (If you're interested in how to fix this problem, see 2setf* ; but this is irrelevant to how macros work.) You can see from this discussion that macros are very different from functions. A function would not be able to tell what kind of subforms are present in a call to it; they get evaluated before the function ever sees them. However, a macro gets to look at the whole form and see just what is going on there. Macros are 1not* functions; if 2first* is defined as a macro, it is not meaningful to apply 2first* to arguments. A macro does not take arguments at all; its expander function takes a 1Lisp form* and turns it into another 1Lisp form*. The purpose of functions is to 1compute*; the purpose of macros is to 1translate*. Macros are used for a variety of purposes, the most common being extensions to the Lisp language. For example, Lisp is powerful enough to express many different control structures, but it does not provide every control structure anyone might ever possibly want. Instead, if a user wants some kind of control structure with a syntax that is not provided, he can translate it into some form that Lisp 1does* know about. For example, someone might want a limited iteration construct which increments a variable by one until it exceeds a limit (like the FOR statement of the BASIC language). He might want it to look like 3(for a 1 100 (print a) (print (* a a)))* To get this, he could write a macro to translate it into 3(do ((a 1 (1+ a))) ((> a 100)) (print a) (print (* a a)))* A macro to do this could be defined with 3(macro for (x ignore)* 3 (list* 'do* 3 (list (list (second x) (third x)* 3 (list '1+ (second x))))* 3 (list (list '> (second x) (fourth x)))* 3 (cddddr x)))* 2for* can now be used as if it were a built-in Lisp control construct. ;;; -*- Mode:gate; Fonts:(HL12 HL12I HL12B CPTFONTB HL12BI HL12B HL12I ) -*- =Node: Aids for Defining Macros =Text: 3AIDS FOR DEFINING MACROS* The main problem with the definition for the 2for* macro is that it is verbose and clumsy. If it is that hard to write a macro to do a simple specialized iteration construct, one would wonder how anyone could write macros of any real sophistication. There are two things that make the definition so inelegant. One is that the programmer must write things like 2(second x)* and 2(cddddr x)* to refer to the parts of the form he wants to do things with. The other problem is that the long chains of calls to the 2list* and 2cons* functions are very hard to read. Two features are provided to solve these two problems. The 2defmacro* macro solves the former, and the ``backquote'' (2`*) reader macro solves the latter. ;;; -*- Mode:gate; Fonts:(HL12 HL12I HL12B CPTFONTB HL12BI HL12B HL12I ) -*- =Node: Defmacro =Text: 3DEFMACRO* Instead of referring to the parts of our form by 2(second x)* and such, we would like to give names to the various pieces of the form, and somehow have the 2(second x)* automatically generated. This is done by a macro called 2defmacro*. It is easiest to explain what 2defmacro* does by showing an example. Here is how you would write the 2for* macro using 2defmacro*: 3(defmacro for (var lower upper . body)* 3 (list* 'do* 3 (list (list var lower (list '1+ var)))* 3 (list (list '> var upper))* 3 body))* The 2(var lower upper . body)* is a 1pattern* to match against the body of the form (to be more precise, to match against the cdr of the argument to the macro's expander function). If 2defmacro* tries to match the two lists 3(var lower upper . body) 1and** 3(a 1 100 (print a) (print (* a a)))* 2var* is bound to the symbol 2a*, 2lower* to the fixnum 21*, 2upper* to the fixnum 2100*, and 2body* to the list 2((print a) (print (* a a)))*. 2var, lower, upper,* and 2body* are then used by the body of the macro definition. 3defmacro* 1Macro* 2defmacro* is a general purpose macro-defining macro. A 2defmacro* form looks like 3(defmacro 1name* 1pattern* . 1body*)* 1name* is the name of the macro to be defined; it can be any function spec (see 4(FUNCTIONS-1)Function Specs*). Normally it is not useful to define anything but a symbol, since that is the only place that the evaluator looks for macro definitions. However, sometimes it is useful to define a 2:property* function spec as a macro, when some part of the system (such as 2locf*) will look for an expander function on a property. The 1pattern* may be anything made up out of symbols and conses. When the macro is called, 1pattern* is matched against the body of the macro form; both 1pattern* and the form are car'ed and cdr'ed identically, and whenever a non-2nil* symbol is hit in 1pattern*, the symbol is bound to the corresponding part of the form. All of the symbols in 1pattern* can be used as variables within 1body*. 1body* is evaluated with these bindings in effect, and its result is returned to the evaluator as the expansion of the macro. Note that the pattern need not be a list the way a lambda-list must. In the above example, the pattern was a dotted list, since the symbol 2body* was supposed to match the cddddr of the macro form. If we wanted a new iteration form, like 2for* except that our example would look like 3(for a (1 100) (print a) (print (* a a)))* (just because we thought that was a nicer syntax), then we could do it merely by modifying the pattern of the 2defmacro* above; the new pattern would be 2(var (lower upper) . body)*. Here is how we would write our other examples using 2defmacro*: 3(defmacro first (the-list)* 3 (list 'car the-list))* 3(defmacro addone (form)* 3 (list 'plus '1 form))* 3(defmacro increment (symbol)* 3 (list 'setq symbol (list '1+ symbol)))* All of these were very simple macros and have very simple patterns, but these examples show that we can replace the 2(cadr x)* with a readable mnemonic name such as 2the-list* or 2symbol*, which makes the program clearer, and enables documentation facilities such as the 2arglist* function to describe the syntax of the special form defined by the macro. The pattern in a 2defmacro* is more like the lambda list of a normal function than revealed above. It is allowed to contain certain 2&*-keywords. Subpatterns of the lambda list pattern can also use 2&*-keywords, a usage not allowed in functions. 2&optional* is followed by 1variable*, 2(1variable*)*, 2(1variable* 1default*)*, or 2(1variable* 1default* 1present-p*)*, exactly the same as in a function. Note that 1default* is still a form to be evaluated, even though 1variable* is not being bound to the value of a form. 1variable* does not have to be a symbol; it can be a pattern. In this case the first form is disallowed because it is syntactically ambigous. The pattern must at least be enclosed in a singleton list. If 1variable* is a pattern, 1default* can be evaluated more than once. Example: 3(defmacro foo (&optional ((x &optional y) '(a)))* 3 ...)* Here the first argument of 2foo* is optional, and should be a list of one or two elements which become 2x* and 2y*. If 2foo* is given no arguments, the list 2(a)* is decomposed to get 2x* and 2y*, so that 2x*'s value is 2a* and 2y*'s value is 2nil*. Using 2&rest* is the same as using a dotted list as the pattern, except that it may be easier to read and leaves a place to put 2&aux*. When 2&key* is used in a defmacro pattern, the keywords are decoded at macro expansion time. Therefore, they must be constants. Example: 3(defmacro l1 (&key a b c) * 3 (list 'list a b c))* 3(l1 :b 5 :c (car d))* 3 ==> (list nil 5 (car d))* 2&aux* is the same in a macro as in a function, and has nothing to do with pattern matching. 2defmacro* implements a few additional keywords not allowed in functions. 2&body* is identical to 2&rest* except that it informs the editor and the grinder that the remaining subforms constitute a ``body'' rather than ordinary arguments and should be indented accordingly. Example: 3(defmacro with-open-file * 3 ((streamvar filename &rest options)* 3 &body body)* 3 ...)* 2&whole* causes the variable that follows it to be bound to the entire macro call, just as the 1form-arg* variable in 2macro* would be. 2&whole* exists to make 2defmacro* able to do anything that 2macro* can be used for, for the sake of Common Lisp, in which 2defmacro* is the primitive and 2macro* does not exist. 2&whole* is also useful in 2macrolet*. 2&environment* causes the variable that follows it to be bound to the 1local macros environment* of the macro call being expanded. This is useful if the code for expanding this macro needs to invoke 2macroexpand* on subforms of the macro call. Then, to achieve correct interaction with 2macrolet*, this local macros environment should be passed to 2macroexpand* as its second argument. 2&list-of* 1pattern* requires that the corresponding position of the form being translated must contain a list (or 2nil*). It matches 1pattern* against each element of that list. Each variable in 1pattern* is bound to a list of the corresponding values in each element of the list matched by the 2&list-of*. This may be clarified by an example. Suppose we want to be able to say things like: 3(send-commands (aref turtle-table i)* 3 (forward 100)* 3 (beep)* 3 (left 90)* 3 (pen 'down 'red)* 3 (forward 50)* 3 (pen 'up))* We could define a 2send-commands* macro as follows: 3(defmacro send-commands (object* 3&body &list-of (command . arguments))* 3 `(let ((o ,object))* 3 . ,(mapcar #'(lambda (com args) `(send o ',com . ,args))* 3command arguments)))* Note that this example uses 2&body* together with 2&list-of*, so you don't see the list itself; the list is just the rest of the macro-form. You can combine 2&optional* and 2&list-of*. Consider the following example: 3(defmacro print-let (x &optional &list-of* 3 ((vars vals)* 3 '((*print-base* 10.)* 3(*print-radix* nil))))* 3 `((lambda (,@vars) (print ,x))* 3 ,@vals))* 3(print-let foo) ==>* 3((lambda (*print-base* *print-radix*)* 3 (print foo))* 3 10 nil)* 3(print-let foo ((bar 3))) ==>* 3((lambda (bar)* 3 (print foo))* 3 3)* In this example we aren't using 2&body* or anything like it, so you do see the list itself; that is why you see parentheses around the 2(bar 3)*. ;;; -*- Mode:gate; Fonts:(HL12 HL12I HL12B CPTFONTB HL12BI HL12B HL12I ) -*- =Node: Backquote =Text: 3BACKQUOTE* Now we deal with the other problem: the long strings of calls to 2cons* and 2list*. This problem is relieved by introducing some new characters that are special to the Lisp reader. Just as the single-quote character makes it easier to type things of the form 2(quote 1x*)*, so backquote and comma make it easier to type forms that create new list structure. They allow you to create a list from a template including constant and variable parts. The backquote facility is used by giving a backquote character (2`*), followed by a list or vector. If the comma character does not appear within the text for the list or vector, the backquote acts just like a single quote: it creates a form which, when evaluated, produces the list or vector specified. For example, 3 '(a b c) => (a b c)* 3 `(a b c) => (a b c)* 3 `#(a b) => #(a b)* So in the simple cases, backquote is just like the regular single-quote macro. The way to get it to do interesting things is to include a comma somewhere inside of the form following the backquote. The comma is followed by a form, and that form gets evaluated even though it is inside the backquote. For example, 3(setq b 1)* 3`(a b c) => (a b c)* 3`(a ,b c) => (a 1 c)* 3`(abc ,(+ b 4) ,(- b 1) (def ,b)) => (abc 5 0 (def 1))* 3`#(a ,b) => #(a 1)* In other words, backquote quotes everything 1except* expressions preceded by a comma; those get evaluated. The list or vector following a backquote can be thought of as a template for some new data structure. The parts of it that are preceded by commas are forms that fill in slots in the template; everything else is just constant structure that appears as written in the result. This is usually what you want in the body of a macro. Some of the form generated by the macro is constant, the same thing on every invocation of the macro. Other parts are different every time the macro is called, often being functions of the form that the macro appeared in (the 1arguments* of the macro). The latter parts are the ones for which you would use the comma. Several examples of this sort of use follow. When the reader sees the 2`(a ,b c)* it is actually generating a form such as 2(list 'a b 'c)*. The actual form generated may use 2list*, 2cons*, 2append*, or whatever might be a good idea; you should never have to concern yourself with what it actually turns into. All you need to care about is what it evaluates to. Actually, it doesn't use the regular functions 2cons*, 2list*, and so forth, but uses special ones instead so that the grinder can recognize a form which was created with the backquote syntax, and print it using backquote so that it looks like what you typed in. You should never write any program that depends on this, anyway, because backquote makes no guarantees about how it does what it does. In particular, in some circumstances it may decide to create constant forms, which will cause sharing of list structure at run time, or it may decide to create forms that will create new list structure at run time. For example, if the reader sees 2`(r . ,nil)*, it may produce the same thing as 2(cons 'r nil)*, or 2'(r . nil)*. Be careful that your program does not depend on which of these it does. This is generally found to be pretty confusing by most people; the best way to explain further seems to be with examples. Here is how we would write our three simple macros using both the 2defmacro* and backquote facilities. 3(defmacro first (the-list)* 3 `(car ,the-list))* 3(defmacro addone (form)* 3 `(plus 1 ,form))* 3(defmacro increment (symbol)* 3 `(setq ,symbol (1+ ,symbol)))* To demonstrate finally how easy it is to define macros with these two facilities, here is the final form of the 2for* macro. 3(defmacro for (var lower upper . body)* 3 `(do ((,var ,lower (1+ ,var))) ((> ,var ,upper)) . ,body))* Look at how much simpler that is than the original definition. Also, look how closely it resembles the code it is producing. The functionality of the 2for* really stands right out when written this way. If a comma inside a backquote form is followed by an at-sign character (`2@*'), it has a special meaning. The `2,@*' should be followed by a form whose value is a list; then each of the elements of the list is put into the list being created by the backquote. In other words, instead of generating a call to the 2cons* function, backquote generates a call to 2append*. For example, if 2a* is bound to 2(x y z)*, then 2`(1 ,a 2)* would evaluate to 2(1 (x y z) 2)*, but 2`(1 ,@a 2)* would evaluate to 2(1 x y z 2)*. Here is an example of a macro definition that uses the `2,@*' construction. One way to define 2do-forever* would be for it to expand 3(do-forever 1form1* 1form2* 1form3*)* into 3(tagbody* 3 a 1form1** 3 1form2** 3 1form3** 3 (go a))* You could define the macro by 3(defmacro do-forever (&body body)* 3 `(tagbody* 3 a ,@body* 3 (go a)))* (This definition has the disadvantage of interfering with use of the 2go* tag 2a* to go from the body of the 2do-forever* to a tag defined outside of it. A more robust implementation would construct a new tag each time, using 2gensym*.) A similar construct is `2,.*' (comma, dot). This means the same thing as `2,@*' except that the list which is the value of the following form may be modified destructively; backquote uses 2nconc* rather than 2append*. This should, of course, be used with caution. Backquote does not make any guarantees about what parts of the structure it shares and what parts it copies. You should not do destructive operations such as 2nconc* on the results of backquote forms such as 3`(,a b c d)* since backquote might choose to implement this as 3(cons a '(b c d))* and 2nconc* would smash the constant. On the other hand, it would be safe to 2nconc* the result of 3`(a b ,c ,d)* since any possible expansion of this would make a new list. One possible expansion is 3(list 'a 'b c d)* Backquote of course guarantees not to do any destructive operations (2rplaca*, 2rplacd*, 2nconc*) on the components of the structure it builds, unless the `2,.*' syntax is used. Advanced macro writers sometimes write macro-defining macros: forms which expand into forms which, when evaluated, define macros. In such macros it is often useful to use nested backquote constructs. For example, here is a very simple version of 2defstruct* (see 4(DEFSTRUCT-1)How to Use Defstruct*) which does not allow any options and only the simplest slot descriptors. Its invocation looks like: 3(defstruct (1name*)* 3 1item1* 1item2* ...)* We would like this form to expand into 3(progn* 3 (defmacro 1item1* (x) `(aref ,x 0))* 3 (defmacro 1item2* (x) `(aref ,x 1))* 3 (defmacro 1item3* (x) `(aref ,x 2))* 3 (defmacro 1item4* (x) `(aref ,x 3))* 3 ...)* Here is the macro to perform the expansion: 3(defmacro defstruct ((name) . items)* 3 (do ((item-list items (cdr item-list))* 3 (ans nil)* 3 (i 0 (1+ i)))* 3 ((null item-list)* 3 `(progn . ,(nreverse ans)))* 3 (push `(defmacro ,(car item-list) (x)* 3`(aref ,x ,',i))* 3 ans)))* The interesting part of this definition is the body of the (inner) 2defmacro* form: 3`(aref ,x ,',i)* Instead of using this backquote construction, we could have written 3(list 'aref x ,i)* That is, the 2,',* acts like a comma that matches the outer backquote, while the comma preceding the 2x* matches with the inner backquote. Thus, the symbol 2i* is evaluated when the 2defstruct* form is expanded, whereas the symbol 2x* is evaluated when the accessor macros are expanded. Backquote can be useful in situations other than the writing of macros. Whenever there is a piece of list structure to be consed up, most of which is constant, the use of backquote can make the program considerably clearer. ;;; -*- Mode:gate; Fonts:(HL12 HL12I HL12B CPTFONTB HL12BI HL12B HL12I ) -*- =Node: Local Macro Definitions =Text: 3LOCAL MACRO DEFINITIONS* 2defmacro* or 2macro* defines a macro whose name has global scope; it can be used in any function anywhere (subject to separation of name spaces by packages). You can also make local macro definitions which are in effect only in one piece of code. This is done with 2macrolet*. Like lexical variable bindings made by 2let* or the local function definitions made by 2flet*, 2macrolet* macro definitions are in effect only for code contained lexically within the body of the 2macrolet* construct. 3macrolet* 1(local-macros...)* 1body...* 1Special Form* Executes 1body* and returns the values of the last form in it, with local macro definitions in effect according to 1local-macros*. Each element of 1local-macros* looks like the cdr of a 2defmacro* form: 3(1name* 1lambda-list* 1macro-body*...)* and it is interpreted just the same way. However, 1name* is only thus defined for expressions appearing within 1body*. 3(macrolet ((ifnot (x y . z) `(if (not ,x) ,y . ,z)))* 3 (ifnot foo (print bar) (print t)))* 3 ==> (if (not foo) (print bar) (print t))* It is permissible for 1name* to have a global definition also, as a macro or as a function. The global definition is shadowed within 1body*. 3(macrolet ((car (x) `(cdr (assq ,x '((a . ferrari)* 3 (b . ford))))))* 3 ...(print (car symbol))...)* makes 2car* have an unusual meaning for its explicit use, but due to lexical scoping it has no effect on what happens if 2print* calls 2car*. 2macrolet* can also hide other local definitions made by 2macrolet*, 2flet* or 2labels* (4(EVAL-3)Local Functions*). ;;; -*- Mode:gate; Fonts:(HL12 HL12I HL12B CPTFONTB HL12BI HL12B HL12I ) -*- =Node: Substitutable Functions =Text: 3SUBSTITUTABLE FUNCTIONS* A substitutable function is a function that is open coded by the compiler. It is like any other function when applied, but it can be expanded instead, and in that regard resembles a macro. 3defsubst* 1Special Form* 2defsubst* is used for defining substitutable functions. It is used just like 2defun*. 3(defsubst 1name* 1lambda-list* . 1body*)* and does almost the same thing. It defines a function that executes identically to the one that a similar call to 2defun* would define. The difference comes when a function that 1calls* this one is compiled. Then, the call is open-coded by substituting the substitutable function's definition into the code being compiled. The function itself looks like 2(named-subst 1name** 1lambda-list2 . *body2)**. Such a function is called a subst. For example, if we define 3(defsubst square (x) (* x x))* 3(defun foo (a b) (square (+ a b)))* then if 2foo* is used interpreted, 2square* works just as if it had been defined by 2defun*. If 2foo* is compiled, however, the squaring is substituted into it and it produces the same code as 3(defun foo (a b) (let ((tem (+ a b))) (* tem tem)))* 2square*'s definition would be 3(named-subst square (x) (* x x))* (The internal formats of substs are explained in 4(FUNCTIONS-1)Interpreted Functions*.) A similar 2square* could be defined as a macro, but the simple way 3(defmacro square (x) `(* ,x ,x))* has a bug: it causes the argument to be computed twice. The simplest correct definition as a macro is 3(defmacro square (x)* 3 (once-only (x)* 3 `(* ,x ,x)))* See 4(MACROS-2)Multiple and Out-of-Order Evaluation* for information on 2once-only*. In general, anything that is implemented as a subst can be re-implemented as a macro, just by changing the 2defsubst* to a 2defmacro* and putting in the appropriate backquote and commas, using 2once-only* or creating temporary variables to make sure the arguments are computed once and in the proper order. The disadvantage of macros is that they are not functions, and so cannot be applied to arguments. Also, the effort required to guarantee the order of evaluation is a disadvantage. Their advantage is that they can do much more powerful things than substs can. This is also a disadvantage since macros provide more ways to get into trouble. If something can be implemented either as a macro or as a subst, it is generally better to make it a subst. The 1lambda-list* of a subst may contain 2&optional* and 2&rest*, but no other lambda-list keywords. If there is a rest argument, it is replaced in the body with an explicit call to 2list*: 3(defsubst append-to-foo (&rest args) * 3 (setq foo (append args foo)))* 3(append-to-foo x y z)* expands to 3(setq foo (append (list x y z) foo))* Rest arguments in substs are most useful with 2apply*. Because of an optimization, if 3(defsubst xhack (&rest indices) * 3 (apply 'xfun xarg1 indices))* has been done then 3(xhack a (car b))* is equivalent to 3(xfun xarg1 a (car b))* If 2xfun* is itself a subst, it is expanded in turn. When a 2defsubst* is compiled, its list structure definition is kept around so that calls can still be open-coded by the compiler. But non-open-coded calls to the function run at the speed of compiled code. The interpreted definition is kept in the compiled definition's debugging info alist (see 4(FUNCTIONS-2)How Programs Examine Functions*). Undeclared free variables used in a 2defsubst* being compiled do not get any warning, because this is a common practice that works properly with nonspecial variables when calls are open coded. If you are using a 2defsubst* from outside the program to which it belongs, you might sometimes be better off if it is not open-coded. The decrease in speed might not be significant, and you would have the advantage that you would not need to recompile your program if the definition is changed. You can prevent open-coding by putting 2dont-optimize* around the call to the 2defsubst*. 3(dont-optimize (xhack a (car b)))* See 4(COMPILER-1)Input to the Compiler*. Straightforward substitution of the arguments could cause arguments to be computed more than once, or in the wrong order. For instance, the functions 3(defsubst reverse-cons (x y) (cons y x))* 3(defsubst in-order (a b c) (and (< a b) (< b c)))* would present problems. When compiled, because of the substitution a call to 2reverse-cons* would evaluate its arguments in the wrong order, and a call to 2in-order* could evaluate its second argument twice. In fact, a more complicated form of substitution (implemented by 2si:sublis-eval-once*, 4(MACROS-3)Extending setf and locf*) is used so that local variables are introduced as necessary to prevent such problems. Note that all occurrences of the argument names in the body are replaced with the argument forms, wherever they appear. Thus an argument name should not be used in the body for anything else, such as a function name or a symbol in a constant. As with 2defun*, 1name* can be any function spec.