Footnotes

(1)

"But no one can read the program without understanding all your new utilities." To see why such statements are usually mistaken, see Section 4.8.

(2)

You could write this more elegantly with the new Common Lisp series macros, but that only proves the same point, because these macros are an extension to Lisp themselves.

(3)

Under dynamic scope the same idiom will work for a different reason--so long as neither of mapcar's parameter is called x.

(4)

The declaration (optimize speed) ought to be an abbreviation for (optimize (speed 3)). However, one Common Lisp implementation does tail-recursion optimization with the former, but not the latter.

(5)

An explanation of why it is bad to call eval explicitly appears on page 278.

It's ok to have this code in a file and then compile the file. The restriction is imposed on interpreted code for implementation reasons, not because there's anything wrong with defining functions in distinct lexical environments.

(7)

For a characteristic example, see page 242.

(8)

A definition of referential transparency appears on page 198.

(9)

For an introduction to packages, see the Appendix beginning on page 381.

(10)

Except perhaps remove-if-not, which is used more often than remove-if.

(11)

Under dynamic scope, we could write something like make-adder, but it would hardly ever work. The binding of n would be determined by the environment in which the returned function was eventually called, and we might not have any control over that.

(12)

In one widely used Common Lisp, functionp erroneously returns true for t and nil. In that implementation it won't work to give either as the second argument to lrec.

(13)

In some implementations, you may have to set *print-circle* to t before these functions can be displayed.

(14)

This version assumes that the network is a tree, which it must be in this application.

(15)

Backquote can also be used to create vectors, but this is rarely done in macro definitions.

(16)

This macro is defined a little oddly to avoid using gensyms. A better definition is given on page 150.

(17)

This version is written in this strange way to avoid using gensyms, which are not introduced till later.

(18)

5 For an example of macro where this distinction matters, see the note on page 393.

(19)

Except functions compiled inline, which impose the same restrictions on redefinition as macros.

(20)

Made from, in the sense that lists are the input to the compiler. Functions are no longer made of lists, as they used to be in some earlier dialects.

(21)

For clarity, this version ignores all the bookkeeping that defun must perform.

(22)

The definition of this macro anticipates the next chapter by using gensyms. Their purpose will be explained shortly.

(23)

This macro is used only as an example. Really it should neither be implemented as a macro, nor use the inefficient algorithm that it does. For a proper definition, see page 50.

(24)

`',(foo) is equivalent to `(quote ,(foo)).

(25)

It's not impossible to write an iteration function which doesn't need its argument wrapped up in a function. We could write a function that called eval on expressions passed to it as arguments. For an explanation of why it's usually bad to call eval, see page 278.

(26)

This definition is not correct, as the following section will explain.

(27)

A function name in the general sense: either 1+ or (lambda (x) (+ x 1)).

(28)

The third value is currently always a list of one element. It is returned as a list to provide the (so far unconsummated) potential to store multiple values in generalized variables.

(29)

Built-in functions should not be memoized in this way, though. Common Lisp forbids the redefinition of built-in functions.

(30)

Although one tends to think of and and or together, there would be no point in writing an anaphoric version of or. An argument in an or expression is evaluated only if the previous argument evaluated to nil, so there would be nothing useful for an anaphor to refer to in an aor.