0

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.

shizhz
  • 11,715
  • 3
  • 39
  • 49

2 Answers2

7

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.

Frédéric Hamidi
  • 258,201
  • 41
  • 486
  • 479
3

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.

Sylwester
  • 47,942
  • 4
  • 47
  • 79
  • Thanks :) BTW, for "Now if your print-base would have been 4 the answer to the above would have been visualized as (2 100).", do you mean set *print-base* to 4? Coz I tried _(let ((*read-base* 2) (*print-base* 4)) (read-from-string "(10 #x10)"))_ but the result is still (2 16) – shizhz Feb 27 '15 at 14:59
  • @seki-shi If you had used `print` to print the result inside `let` you would have got printed `(2 100)` and then returned `(2 16)` since the `*print-base*` was different. To get the REPL to print in base 4 you need to use `setf/setq` since the REPL displays the result which is the result of the `let` after the local bindings are gone. eg `(setf *print-base* 4)` – Sylwester Feb 27 '15 at 15:10