Original JavaScript
Figure 3.21 Lists x: ((a b) c d) and y: (e f).
Figure 3.22 Lists x: list(list("a", "b"), "c", "d") and y: list("e", "f").
Original JavaScript
Figure 3.23 Effect of (set-car! x y) on the lists in figure 3.21.
Figure 3.24 Effect of set_head(x, y) on the lists in figure 3.22.
Original JavaScript
Figure 3.25 Effect of (define z (cons y (cdr x))) on the lists in figure 3.21.
Figure 3.26 Effect of const z = pair(y, tail(x)); on the lists in figure 3.22.
Original JavaScript
Figure 3.27 Effect of (set-cdr! x y) on the lists in figure 3.21.
Figure 3.28 Effect of set_tail(x, y) on the lists in figure 3.22.

[1]
Original JavaScript
Set-car! and set-cdr! return implementation-dependent values. Like set!, they should be used only for their effect. The functions set_head and set_tail return the value undefined. They should be used only for their effect.
[2] We see from this that mutation operations on lists can create garbage that is not part of any accessible structure. We will see in section 5.3.2 that Lisp JavaScript memory-management systems include a garbage collector, which identifies and recycles the memory space used by unneeded pairs.
[3]
Original JavaScript
Get-new-pair is one of the operations that must be implemented as part of the memory management required by a Lisp implementation. We will discuss this in section 5.3.1. Section 5.3.1 will show how a memory-management system can implement get_new_pair.
[4] The two pairs are distinct because each call to cons returns a new pair. The symbols are shared; in Scheme there is a unique symbol with any given name. Since Scheme provides no way to mutate a symbol, this sharing is undetectable. Note also that the sharing is what enables us to compare symbols using eq?, which simply checks equality of pointers.
[5] The two pairs are distinct because each call to pair returns a new pair. The strings are the same in the sense that they are primitive data (just like numbers) that are composed of the same characters in the same order. Since JavaScript provides no way to mutate a string, any sharing that the designers of a JavaScript interpreter might decide to implement for strings is undetectable. We consider primitive data such as numbers, booleans, and strings to be identical if and only if they are indistinguishable.
[6] The subtleties of dealing with sharing of mutable data objects reflect the underlying issues of sameness and change that were raised in section 3.1.3. We mentioned there that admitting change to our language requires that a compound object must have an identity that is something different from the pieces from which it is composed. In Lisp, JavaScript, we consider this identity to be the quality that is tested by eq?, ===, i.e., by equality of pointers. Since in most Lisp JavaScript implementations a pointer is essentially a memory address, we are solving the problem of defining the identity of objects by stipulating that a data object itself is the information stored in some particular set of memory locations in the computer. This suffices for simple Lisp JavaScript programs, but is hardly a general way to resolve the issue of sameness in computational models.
[7] On the other hand, from the viewpoint of implementation, assignment requires us to modify the environment, which is itself a mutable data structure. Thus, assignment and mutation are equipotent: Each can be implemented in terms of the other.
3.3.1   Mutable List Structure