Editing Lisp (programming language) (section)

====Shared structure====
Lisp lists, being simple linked lists, can share structure with one another. That is to say, two lists can have the same ''tail'', or final sequence of conses. For instance, after the execution of the following Common Lisp code:
<syntaxhighlight lang="Lisp">
(setf foo (list 'a 'b 'c))
(setf bar (cons 'x (cdr foo)))
</syntaxhighlight>
the lists {{Lisp2|foo}} and {{Lisp2|bar}} are {{Lisp2|(a b c)}} and {{Lisp2|(x b c)}} respectively. However, the tail {{Lisp2|(b c)}} is the same structure in both lists. It is not a copy; the cons cells pointing to {{Lisp2|b}} and {{Lisp2|c}} are in the same memory locations for both lists.

Sharing structure rather than copying can give a dramatic performance improvement. However, this technique can interact in undesired ways with functions that alter lists passed to them as arguments. Altering one list, such as by replacing the {{Lisp2|c}} with a {{Lisp2|goose}}, will affect the other:
<syntaxhighlight lang="Lisp">
 (setf (third foo) 'goose)
</syntaxhighlight>
This changes {{Lisp2|foo}} to {{Lisp2|(a b goose)}}, but thereby also changes {{Lisp2|bar}} to {{Lisp2|(x b goose)}} – a possibly unexpected result. This can be a source of bugs, and functions which alter their arguments are documented as ''destructive'' for this very reason.

Aficionados of [[functional programming]] avoid destructive functions. In the Scheme dialect, which favors the functional style, the names of destructive functions are marked with a cautionary exclamation point, or "bang"—such as {{Lisp2|set-car!}} (read ''set car bang''), which replaces the car of a cons. In the Common Lisp dialect, destructive functions are commonplace; the equivalent of {{Lisp2|set-car!}} is named {{Lisp2|rplaca}} for "replace car". This function is rarely seen, however, as Common Lisp includes a special facility, {{Lisp2|setf}}, to make it easier to define and use destructive functions. A frequent style in Common Lisp is to write code functionally (without destructive calls) when prototyping, then to add destructive calls as an optimization where it is safe to do so.