Trees

Treating structures built from cons cells as trees is just about as natural as treating them as lists. What is a list of lists, after all, but another way of thinking of a tree? The difference between a function that treats a bunch of cons cells as a list and a function that treats the same bunch of cons cells as a tree has to do with which cons cells the functions traverse to find the values of the list or tree. The cons cells traversed by a list function, called the list structure, are found by starting at the first cons cell and following **CDR** references until reaching a **NIL**. The elements of the list are the objects referenced by the **CAR**s of the cons cells in the list structure. If a cons cell in the list structure has a **CAR** that references another cons cell, the referenced cons cell is considered to be the head of a list that’s an element of the outer list.1 Tree structure, on the other hand, is traversed by following both **CAR** and **CDR** references for as long as they point to other cons cells. The values in a tree are thus the atomic—non-cons-cell-values referenced by either the **CAR**s or the **CDR**s of the cons cells in the tree structure.

For instance, the following box-and-arrow diagram shows the cons cells that make up the list of lists: ((1 2) (3 4) (5 6)). The list structure includes only the three cons cells inside the dashed box while the tree structure includes all the cons cells.

To see the difference between a list function and a tree function, you can consider how the functions **COPY-LIST** and **COPY-TREE** will copy this bunch of cons cells. **COPY-LIST**, as a list function, copies the cons cells that make up the list structure. That is, it makes a new cons cell corresponding to each of the cons cells inside the dashed box. The **CAR**s of each of these new cons cells reference the same object as the **CAR**s of the original cons cells in the list structure. Thus, **COPY-LIST** doesn’t copy the sublists (1 2), (3 4), or (5 6), as shown in this diagram:

**COPY-TREE**, on the other hand, makes a new cons cell for each of the cons cells in the diagram and links them together in the same structure, as shown in this diagram:

Where a cons cell in the original referenced an atomic value, the corresponding cons cell in the copy will reference the same value. Thus, the only objects referenced in common by the original tree and the copy produced by **COPY-TREE** are the numbers 1-6, and the symbol **NIL**.

Another function that walks both the **CAR**s and the **CDR**s of a tree of cons cells is **TREE-EQUAL**, which compares two trees, considering them equal if the tree structure is the same shape and if the leaves are **EQL** (or if they satisfy the test supplied with the :test keyword argument).

Some other tree-centric functions are the tree analogs to the **SUBSTITUTE** and **NSUBSTITUTE** sequence functions and their -IF and -IF-NOT variants. The function **SUBST**, like **SUBSTITUTE**, takes a new item, an old item, and a tree (as opposed to a sequence), along with :key and :test keyword arguments, and it returns a new tree with the same shape as the original tree but with all instances of the old item replaced with the new item. For example:

CL-USER> (subst 10 1 '(1 2 (3 2 1) ((1 1) (2 2))))
(10 2 (3 2 10) ((10 10) (2 2)))

**SUBST-IF** is analogous to **SUBSTITUTE-IF**. Instead of an old item, it takes a one-argument function—the function is called with each atomic value in the tree, and whenever it returns true, the position in the new tree is filled with the new value. **SUBST-IF-NOT** is the same except the values where the test returns **NIL** are replaced. **NSUBST**, **NSUBST-IF**, and **NSUBST-IF-NOT** are the recycling versions of the **SUBST** functions. As with most other recycling functions, you should use these functions only as drop-in replacements for their nondestructive counterparts in situations where you know there’s no danger of modifying a shared structure. In particular, you must continue to save the return value of these functions since you have no guarantee that the result will be **EQ** to the original tree.2