Книга: Practical Common Lisp
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
CARs 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. Tree structure, on the other hand, is traversed by following both
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
CARs or the
CDRs 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-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
CARs of each of these new cons cells reference the same object as the
CARs of the original cons cells in the list structure. Thus,
COPY-LIST doesn't copy the sublists
(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 5, 6, and the symbol
Another function that walks both the
CARs and the
CDRs 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
NSUBSTITUTE sequence functions and their
-IF-NOT variants. The function
SUBSTITUTE, takes a new item, an old item, and a tree (as opposed to a sequence), along with
: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)))) is analogous to
(10 2 (3 2 10) ((10 10) (2 2)))
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-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.