Now, it may seem that the benefits of having another way to extend the language would be easy to recognize. But for some reason a lot of folks who haven't actually used Lisp macros—folks who think nothing of spending their days creating new functional abstractions or defining hierarchies of classes to solve their programming problems —get spooked by the idea of being able to define new syntactic abstractions. The most common cause of macrophobia seems to be bad experiences with other 'macro' systems. Simple fear of the unknown no doubt plays a role, too. To avoid triggering any macrophobic reactions, I'll ease into the subject by discussing several of the standard control-construct macros defined by Common Lisp. These are some of the things that, if Lisp didn't have macros, would have to be built into the language core. When you use them, you don't have to care that they're implemented as macros, but they provide a good example of some of the things you can do with macros.[86] In the next chapter, I'll show you how you can define your own macros.
As you've already seen, the most basic form of conditional execution—if IF
special operator, which has this basic form:
(if
The NIL
, the NIL
and there's no IF
returns NIL
.
(if (> 2 3) 'Yup' 'Nope') ==> 'Nope'
(if (> 2 3) 'Yup') ==> NIL
(if (> 3 2) 'Yup' 'Nope') ==> 'Yup'
However, IF
isn't actually such a great syntactic construct because the
(if (spam-p current-message)
(file-in-spam-folder current-message)
(update-spam-database current-message))
because the call to update-spam-database
will be treated as the else clause, not as part of the then clause. Another special operator, PROGN
, executes any number of forms in order and returns the value of the last form. So you could get the desired behavior by writing the following:
(if (spam-p current-message)
(progn
(file-in-spam-folder current-message)
(update-spam-database current-message)))
That's not too horrible. But given the number of times you'll likely have to use this idiom, it's not hard to imagine that you'd get tired of it after a while. 'Why,' you might ask yourself, 'doesn't Lisp provide a way to say what I really want, namely, 'When IF
plus a PROGN
and wish for a way to abstract away the details rather than writing them out every time.
This is exactly what macros provide. In this case, Common Lisp comes with a standard macro, WHEN
, which lets you write this:
(when (spam-p current-message)
(file-in-spam-folder current-message)
(update-spam-database current-message))
But if it wasn't built into the standard library, you could define WHEN
yourself with a macro such as this, using the backquote notation I discussed in Chapter 3:[87]
(defmacro when (condition &rest body)
`(if ,condition (progn ,@body)))
A counterpart to the WHEN
macro is UNLESS
, which reverses the condition, evaluating its body forms only if the condition is false. In other words:
(defmacro unless (condition &rest body)
`(if (not ,condition) (progn ,@body)))
Admittedly, these are pretty trivial macros. There's no deep black magic here; they just abstract away a few language-level bookkeeping details, allowing you to express your true intent a bit more clearly. But their very triviality makes an important point: because the macro system is built right into the language, you can write trivial macros like WHEN
and UNLESS
that give you small but real gains in clarity that are then multiplied by the thousands of times you use them. In Chapters 24, 26, and 31 you'll see how macros can also be used on a larger scale, creating whole domain-specific embedded languages. But first let's finish our discussion of the standard control-construct macros.
Another time raw IF
expressions can get ugly is when you have a multibranch conditional: if IF
, but it's not pretty.
(if a
(do-x)
(if b
(do-y)
(do-z)))
And it would be even worse if you needed to include multiple forms in the then clauses, requiring PROGN
s. So, not surprisingly, Common Lisp provides a macro for expressing multibranch conditionals: COND
. This is the basic skeleton:
(cond
(
.
.
.
(
Each element of the body represents one branch of the conditional and consists of a list containing a condition form and zero or more forms to be evaluated if that branch is chosen. The conditions are evaluated in the order