CODEWITHSUNDEEP
lispcommon-lispsbclquote
shizhz
shizhz

Reputation: 12501

Common Lisp: How to quote parenthese in SBCL

In Common Lisp, the special operator quote makes whatever followed by un-evaluated, like

(quote a) -> a
(quote {}) -> {}

But why the form (quote ()) gives me nil? I'm using SBCL 1.2.6 and this is what I got in REPL:

CL-USER> (quote ())
NIL

More about this problem: This is some code from PCL Chapter 24

(defun as-keyword (sym)
  (intern (string sym) :keyword))

(defun slot->defclass-slot (spec)
  (let ((name (first spec)))
    `(,name :initarg ,(as-keyword name) :accessor ,name)))

(defmacro define-binary-class (name slots)
  `(defclass ,name ()
     ,(mapcar #'slot->defclass-slot slots)))

When the macro expand for the following code:

(define-binary-class id3-tag
    ((major-version)))

is

(DEFCLASS ID3-TAG NIL
      ((MAJOR-VERSION :INITARG :MAJOR-VERSION :ACCESSOR MAJOR-VERSION)))

which is NIL rather than () after the class name ID3-TAG.

Upvotes: 0

Views: 197

Answers (2)

Frédéric Hamidi
Frédéric Hamidi

Reputation: 262949

nil and () are two ways to express the same concept (the empty list).

Traditionally, nil is used to emphasize the boolean value "false" rather than the empty list, and () is used the other way around.

The Common LISP HyperSpec says:

() ['nil], n. an alternative notation for writing the symbol nil, used to emphasize the use of nil as an empty list.

Upvotes: 7

Sylwester
Sylwester

Reputation: 48745

Your observation is due to an object to having more than one representation. In Common Lisp the reader (that reads code and reads expressions) parses text to structure and data. When it's data the writer can print it out again but it won't know exactly how the data was represented when it was initially read in. The writer will print one object exactly one way, following defaults and settings, even though there are several representations for that object.

As you noticed nil, NIL, nIL, NiL, ... ,'nil, 'NIL, (), and '() are all read as the very same object. I'm not sure the standard dictates exactly how it's default representation out should be so I guess some implementations choose one of NIL, nil or maybe even ().

With cons the representation is dependent on the cdr being a cons/nil or not: 

'(a . nil)        ; ==> (a)
'(a . (b . c))    ; ==> (a b . c)
'(a . (b . nil))  ; ==> (a b)

With numbers the reader can get hints about which base you are using. If no base is used in the text it will use whatever *read-base* is:

(let ((*read-base* 2)) ; read numbers as boolean
  (read-from-string "(10 #x10)")) ; ==> (2 16)

#x tells the reader to interpret the rest as a hexadecimal value. Now if your print-base would have been 4 the answer to the above would have been visualized as (2 100).

To sum it up.. A single value in Common Lisp may have several good representations and all of them would yield the very same value. How the value is printed will follow both implementation, settings and even arguments to the functions that produce them. Neither what it accepts as values in or the different ways it can visualize the value tells nothing about how the value actually gets stored internally.

Upvotes: 3

Related Questions