They are not exactly the same, even though they evaluate to the same values in the REPL. Consider these examples, in which cons cells are modified destructively:
TEST> (defun literal-cons ()
(let ((cons '(1 . 2)))
(incf (cdr cons))
cons))
LITERAL-CONS
TEST> (literal-cons)
(1 . 3)
TEST> (literal-cons)
(1 . 4)
TEST> (literal-cons)
(1 . 5)
Compared to this:
TEST> (defun non-literal-cons ()
(let ((cons (cons 1 2)))
(incf (cdr cons))
cons))
NON-LITERAL-CONS
TEST> (non-literal-cons)
(1 . 3)
TEST> (non-literal-cons)
(1 . 3)
In the first version, you are changing the literal cons cell in the code itself (thus, this is self-modifying code). In the second version, the cons cell is not literal. It is produced every time the code is called, and only this fresh cons cell will be changed.
TEST> (function-lambda-expression #'literal-cons)
(LAMBDA NIL
(DECLARE (CCL::GLOBAL-FUNCTION-NAME LITERAL-CONS))
(BLOCK LITERAL-CONS (LET ((CONS '(1 . 5))) (INCF (CDR CONS)) CONS))) ;; notice the '(1 . 5)
NIL
LITERAL-CONS
Since this can lead to subtle bugs when using destructive operations, one should be careful with such literal objects in code. This also affects list literals ('(1 2 3)
vs. (list 1 2 3)
), which are built from cons cells.
From the HyperSpec:
literal adj. (of an object) referenced directly in a program rather
than being computed by the program; that is, appearing as data in a
quote form, or, if the object is a self-evaluating object, appearing
as unquoted data. ``In the form (cons "one" '("two")), the expressions
"one", ("two"), and "two" are literal objects.''
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…