Is Clojure less homoiconic than other lisps? [closed]

Question

A claim that I recall being repeated in the Clojure for Lisp Programmers videos is that a great weakness of the earlier Lisps, particularly Common Lisp, is that too much is married to the list structure of Lisps, particularly cons cells. You can find one occurrence of this claim just at the 25 minute mark in the linked video, but I'm sure that I can remember hearing it elsewhere in the series. Importantly, at that same point in the video, we see this slide, showing us that Clojure has many other data structures than just the old school Lispy lists: This troubles me. My knowledge of Lisp is quite limited, but I've always been told that a key element of its legendary metaprogrmmability is that everything - yes, everything - is a list and that this is what prevents the sort of errors that we get when trying to metaprogram other languages. Does this suggest that by adding new first-class data structures, Clojure has reduces its homoiconicity, thus making it more difficult to metaprogram than other Lisps, such as Common Lisp?

Answer 1

is that everything - yes, everything - is a list

that has never been true for Lisp

CL-USER 1 > (defun what-is-it? (thing)
              (format t "~%~s is of type ~a.~%" thing (type-of thing))
              (format t "It is ~:[not ~;~]a list.~%" (listp thing))
              (values))
WHAT-IS-IT?

CL-USER 2 > (what-is-it? "hello world")

"hello world" is of type SIMPLE-TEXT-STRING.
It is not a list.

CL-USER 3 > (what-is-it? #2a((0 1) (2 3)))

#2A((0 1) (2 3)) is of type (SIMPLE-ARRAY T (2 2)).
It is not a list.

CL-USER 4 > (defstruct foo bar baz)
FOO

CL-USER 5 > (what-is-it? #S(foo :bar oops :baz zoom))

#S(FOO :BAR OOPS :BAZ ZOOM) is of type FOO.
It is not a list.

CL-USER 6 > (what-is-it? 23749287349723/840283423)

23749287349723/840283423 is of type RATIO.
It is not a list.

and because Lisp is a programmable programming language, we can add external representations for non-list data types:

Add a primitive notation for a FRAME class.

CL-USER 10 > (defclass frame () (slots))
#<STANDARD-CLASS FRAME 4210359BEB>

The printer:

CL-USER 11 > (defmethod print-object ((o frame) stream)
               (format stream "[~{~A~^ ~}]"
                       (when (and (slot-boundp o 'slots)
                                  (slot-value o 'slots))
                         (slot-value o 'slots))))
#<STANDARD-METHOD PRINT-OBJECT NIL (FRAME T) 40200011C3>

The reader:

CL-USER 12 > (set-macro-character
               #\[
               (lambda (stream char)
                 (let ((slots (read-delimited-list #\] stream))
                       (o (make-instance 'frame)))
                   (when slots
                     (setf (slot-value o 'slots) slots))
                   o)))
T

CL-USER 13 > (set-syntax-from-char #\] #\))
T

Now we can read/print these objects:

CL-USER 14 > [a b]
[A B]

CL-USER 15 > (what-is-it? [a b])

[A B] is of type FRAME.
It is not a list.

Answer 2

Let's break the word "homoiconicity" apart.

• homo-, meaning "same"
• iconic, here meaning something like "represented by"
• -ity, meaning "something having such a property"

The quality that makes macros possible (or at least much easier) is that the language itself is represented with the same data structures that you use to represent other objects. Note that the word is not "monolistism", or "everything is a list". Since Clojure uses the same data structures to describe its syntax as it does to describe other values at runtime, there's no excuse to claim it is not homoiconic.

Funnily enough, I might say that one of the ways that Clojure is least homoiconic is a feature that it actually shares with older lisps: it uses symbols to represent source code. In other lisps, this is very natural, because symbols are used for lots of other things. Clojure has keywords, though, which are used much more often to give names to data at runtime. Symbols are quite rarely used; I would go so far as to say that their primary usage is for representing source code elements! But all of the other features Clojure uses to represent source code elements are frequently used to represent other things as well: sequences, vectors, maps, strings, numbers, keywords, occasionally sets, and probably some other niche stuff I'm not thinking of now.

Answer 3

In Clojure, the only one of those extra data structures that is required for some language constructs, besides lists, are vectors, and those are in well-known places such as around sequences of arguments to a function, or in symbol/expression pairs of a let. All of them can be used for data literals, but data literals are less often something you want to involve when writing a Clojure macro, as compared to function calls and macro invocations, which are always in lists.

I am not aware of anything in Clojure that makes writing macros more difficult than in Common Lisp, and there are a few features there distinct to Clojure that can make it a little bit easier, such as the behavior where Clojure backquoted expressions by default will namespace-qualify symbols, which is often what you want to prevent 'capturing' a name accidentally.

Answer 4

As previous answerers pointed out, "homoiconicity" means nothing else than that the famous "code is data": That the code of a programming language consists 100% of data structures of that language, thus is easily build-able and manipulateable with the functions in the language usually used to manipulate the data structures.

Since Clojure data structures include lists, vectors, maps ... (those you listed) and since Clojure code is made of lists, vectors, maps ... Clojure code is homoiconic.

The same is true for Common Lisp and other lisps.

Common Lisp contains also lists, vectors, hash-tables etc. . However, the code of Common Lisp sticks more rigidly to lists than Clojure does (function arguments are in a argument list and not in a vector like in Clojure). So you can more consistently use functions to manipulate lists for metaprogramming purposes (macros).

Whether this is "more" homoiconic than Clojure is a philosophical question. But definitely you need a smaller set of functions for manipulation of the code than in Clojure.