In Common Lisp, quoted objects are constant literal data. The data is not evaluated. You should not modify this data, as the consequences are undefined. Possible consequences are: modification of shared data, attempt to modify read-only data, an error might be signalled, it might just work, shared data, ...
Literal lists:
(1 2 3)
Above is a constant list, which will be constructed by the reader and evaluating to itself, because it is quoted. If it appears in Lisp code, a compiler will embed this data somehow in the FASL code.
(quote (1 2 3))
is another way to write it.
(list 1 2 3)
this is a call of the Common Lisp function LIST
with three arguments 1
, 2
and 3
. Each of the arguments will be evaluated. Since they are numbers, they evaluate to themselves. When evaluated the result is a fresh new list (1 2 3)
.
Data sharing in compiled code
Imagine in a Lisp file the following four definitions:
(defparameter *list1* (list 1 2 3))
(defparameter *list2* (list 1 2 3))
(defparameter *list3* (1 2 3))
(defparameter *list4* (1 2 3))
Then we compile and load the file.
! (eq *list3* *list4*)
now may evaluate to either T
or NIL
depending on the implementation and compiler settings !
Reason: in Common Lisp the Lisp compiler may share structure of literal lists (!) if they are similar. The compiler detects that here the lists are similar and will allocate only one list. Both variables *list1*
and *list2*
the will point to this one list.
All other EQ
(object equality) comparisons of two of the above lists will return NIL
.
Notations for some other data structures:
(1 . 2) and (cons 1 2) ; cons cell
#(1 2 3) and (vector 1 2 3) ; vector
#S(FOO :a 1 :b 2) and (make-foo :a 1 :b 2) ; structure
One is the literal data and the other is a function call that constructs such a data structure.