Peter Siebel - Practical Common Lisp

To see what this misunderstanding looks like, find any longish Usenet thread cross-posted between comp.lang.lisp and any other comp.lang.* group with macro in the subject. A rough paraphrase goes like this:

Lispnik: "Lisp is the best because of its macros!";

Othernik: "You think Lisp is good because of macros?! But macros are horrible and evil; Lisp must be horrible and evil."

Another important class of language constructs that are defined using macros are all the definitional constructs such as DEFUN , DEFPARAMETER , DEFVAR , and others. In Chapter 24 you'll define your own definitional macros that will allow you to concisely write code for reading and writing binary data.

You can't actually feed this definition to Lisp because it's illegal to redefine names in the COMMON-LISPpackage where WHEN comes from. If you really want to try writing such a macro, you'd need to change the name to something else, such as my-when.

The special operators, if you must know, are TAGBODY and GO . There's no need to discuss them now, but I'll cover them in Chapter 20.

DOLIST is similar to Perl's foreachor Python's for. Java added a similar kind of loop construct with the "enhanced" forloop in Java 1.5, as part of JSR-201. Notice what a difference macros make. A Lisp programmer who notices a common pattern in their code can write a macro to give themselves a source-level abstraction of that pattern. A Java programmer who notices the same pattern has to convince Sun that this particular abstraction is worth adding to the language. Then Sun has to publish a JSR and convene an industry-wide "expert group" to hash everything out. That process—according to Sun—takes an average of 18 months. After that, the compiler writers all have to go upgrade their compilers to support the new feature. And even once the Java programmer's favorite compiler supports the new version of Java, they probably still can't use the new feature until they're allowed to break source compatibility with older versions of Java. So an annoyance that Common Lisp programmers can resolve for themselves within five minutes plagues Java programmers for years.

A variant of DO , DO* , assigns each variable its value before evaluating the step form for subsequent variables. For more details, consult your favorite Common Lisp reference.

The DOTIMES is also preferred because the macro expansion will likely include declarations that allow the compiler to generate more efficient code.

Loop keywords is a bit of a misnomer since they aren't keyword symbols. In fact, LOOP doesn't care what package the symbols are from. When the LOOP macro parses its body, it considers any appropriately named symbols equivalent. You could even use true keywords if you wanted— :for, :across, and so on—because they also have the correct name. But most folks just use plain symbols. Because the loop keywords are used only as syntactic markers, it doesn't matter if they're used for other purposes—as function or variable names.

As with functions, macros can also contain declarations, but you don't need to worry about those for now.

APPEND , which I haven't discussed yet, is a function that takes any number of list arguments and returns the result of splicing them together into a single list.

Another function, MACROEXPAND , keeps expanding the result as long as the first element of the resulting expansion is the name of the macro. However, this will often show you a much lower-level view of what the code is doing than you want, since basic control constructs such as DO are also implemented as macros. In other words, while it can be educational to see what your macro ultimately expands into, it isn't a very useful view into what your own macros are doing.

If the macro expansion is shown all on one line, it's probably because the variable *PRINT-PRETTY* is NIL . If it is, evaluating (setf *print-pretty* t)should make the macro expansion easier to read.

This is from Joel on Software by Joel Spolsky, also available at http://www.joelonsoftware.com/ articles/LeakyAbstractions.html. Spolsky's point in the essay is that all abstractions leak to some extent; that is, there are no perfect abstractions. But that doesn't mean you should tolerate leaks you can easily plug.

Of course, certain forms are supposed to be evaluated more than once, such as the forms in the body of a do-primesloop.

It may not be obvious that this loop is necessarily infinite given the nonuniform occurrences of prime numbers. The starting point for a proof that it is in fact infinite is Bertrand's postulate, which says for any n > 1, there exists a prime p , n < p < 2n . From there you can prove that for any prime number, P less than the sum of the preceding prime numbers, the next prime, P', is also smaller than the original sum plus P.

This is for illustrative purposes only—obviously, writing test cases for built-in functions such as + is a bit silly, since if such basic things aren't working, the chances the tests will be running the way you expect is pretty slim. On the other hand, most Common Lisps are implemented largely in Common Lisp, so it's not crazy to imagine writing test suites in Common Lisp to test the standard library functions.

Side effects can include such things as signaling errors; I'll discuss Common Lisp's error handling system in Chapter 19. You may, after reading that chapter, want to think about how to incorporate tests that check whether a function does or does not signal a particular error in certain situations.

I'll discuss this and other FORMAT directives in more detail in Chapter 18.

If test-+has been compiled—which may happen implicitly in certain Lisp implementations—you may need to reevaluate the definition of test-+to get the changed definition of checkto affect the behavior of test-+. Interpreted code, on the other hand, typically expands macros anew each time the code is interpreted, allowing the effects of macro redefinitions to be seen immediately.

You have to change the test to make it fail since you can't change the behavior of + .

Though, again, if the test functions have been compiled, you'll have to recompile them after changing the macro.

As you'll see in Chapter 12, APPEND ing to the end of a list isn't the most efficient way to build a list. But for now this is sufficient—as long as the test hierarchies aren't too deep, it should be fine. And if it becomes a problem, all you'll have to do is change the definition of deftest.