I'm new to Lisp. I encountered 2 terms "list" and "S-expression". I just can't distinguish between them. Are they just synonyms in Lisp?
-
3For more information, see the [C2 wiki on sexprs](http://c2.com/cgi/wiki?EssExpressions). – Asherah May 27 '12 at 04:08
5 Answers
First, not all S-expressions represent lists; an expression such as foobar
, representing a bare atom, is also considered an S-expression. As is the "cons cell" syntax, (car . cons)
, used when the "cons" part is not itself another list (or nil). The more familiar list expression, such as (a b c d)
, is just syntactic sugar for a chain of nested cons cells; that example expands to (a . (b . (c . (d . nil))))
.
Second, the term "S-expression" refers to the syntax - (items like this (possibly nested))
. Such an S-expression is the representation in Lisp source code of a list, but it's not technically a list itself. This distinction is the same as that between a sequence of decimal digits and their numeric value, or between a sequence of characters within quotation marks and the resulting string.
That is perhaps an overly technical distinction; programmers routinely refer to literal representations of values as though they were the values themselves. But with Lisp and lists, things get a little trickier because everything in a Lisp program is technically a list.
For example, consider this expression:
(+ 1 2)
The above is a straightforward S-expression which represents a flat list, consisting of the atoms +
, 1
, and 2
.
However, within a Lisp program, such a list will be interpreted as a call to the +
function with 1 and 2 as arguments. (Do note that is the list, not the S-expression, that is so interpreted; the evaluator is handed lists that have been pre-parsed by the reader, not source code text.)
So while the above S-expression represents a list, it would only rarely be referred to as a "list" in the context of a Lisp program. Unless discussing macros, or the inner workings of the reader, or engaged in a metasyntactic discussion because of some other code-generation or parsing context, a typical Lisp programmer would instead treat the above as a numeric expression.
On the other hand, any of the following S-expressions likely would be referred to as "lists", because evaluating them as Lisp code would produce the list represented by the above literal S-expression as a runtime value:
'(+ 1 2)
(quote (+ 1 2))
(list '+ 1 2)
Of course, the equivalence of code and data is one of the cool things about Lisp, so the distinction is fluid. But my point is that while all of the above are S-expressions and lists, only some would be referred to as "lists" in casual Lisp-speak.

- 91,912
- 16
- 138
- 175
-
list is a cons cell chain with NIL sentinel. that' all. the *reader* converts text into S-expressions -- everything is S-expression in LISP -- it is either atom or a cons cell (vectors are atoms, etc.). the reader [makes no attempt to validate the argument for `eval`](http://ideone.com/o6vIpG). – Will Ness Oct 02 '16 at 18:33
-
1S-expressions are not output by the reader. An "S-expression" refers to the textual representation, with the parentheses and so on. By the time the reader is done with it, it's no longer an S-expression, but already an actual list in memory - that "cons cell chain with nil sentinel" you mentioned. – Mark Reed Oct 02 '16 at 22:41
S-expressions are a notation for data.
Historically an s-expression (short for symbolic expression) is described as:
- symbols like
FOO
andBAR
- cons cells with s-expressions as its first and second element :
(
expression-1.
expression-2)
- the list termination symbol
NIL
- and a convention to write lists:
(
A
.
(
B
.
NIL
)
)
is simpler written as the list(A B)
Note also that historically program text was written differently. An example for the function ASSOC
.
assoc[x;y] =
eq[caar[y];x] -> cadar[y];
T -> assoc[x;cdr[y]]
Historically there existed also a mapping from these m-expressions (short for meta expressions) to s-expressions. Today most Lisp program code is written using s-expressions.
This is described here: McCarthy, Recursive Functions of Symbolic Expressions
In a Lisp programming language like Common Lisp nowadays s-expressions have more syntax and can encode more data types:
- Symbols:
symbol123
,|This is a symbol with spaces|
- Numbers:
123
,1.0
,1/3
, ... - Strings:
"This is a string"
- Characters:
#\a
,#\space
- Vectors:
#(a b c)
- Conses and lists:
( a . b )
,(a b c)
- Comments:
; this is a comment
,#| this is a comment |#
and more.
Lists
A list is a data structure. It consists of cons cells and a list end marker. Lists have in Lisp a notation as lists in s-expressions. You could use some other notations for lists, but in Lisp one has settled on the s-expression syntax to write them.
Side note: programs and forms
In a programming language like Common Lisp, the expressions of the programming language are not text, but data! This is different from many other programming languages. Expressions in the programming language Common Lisp are called Lisp forms
.
For example a function call is Lisp data, where the call is a list with a function symbol as its first element and the next elements are its arguments.
We can write that as (sin 3.0)
. But it really is data. Data we can also construct.
The function to evaluate Lisp forms is called EVAL
and it takes Lisp data, not program text or strings of program text. Thus you can construct programs using Lisp functions which return Lisp data: (EVAL (LIST 'SIN 3.0))
evaluates to 0.14112
.
Since Lisp forms have a data representation, they are usually written using the external data representation of Lisp - which is what? - s-expressions!
It is s-expressions. Lisp forms as Lisp data are written externally as s-expression.

- 136,269
- 10
- 221
- 346
-
2S-expressions came first. They were never intended to be what the programmer saw, but rather an intermediate representation. However, it took a while to come up with the top-level representation, M-expressions, and it didn't impress the team. By that time everyone had decided they liked S-expressions as-is. So even historically, it was always S-expressions all the way down; M-expressions are a footnote at best. – Mark Reed May 27 '12 at 04:58
-
1@Mark Reed: McCarthy's paper from 1960 describes both symbolic expressions and meta expressions. – Rainer Joswig May 27 '12 at 05:01
-
So it does, @rainerjoswig. I guess I misremembered. Thanks for the correction. – Mark Reed May 27 '12 at 05:12
-
You said "cons cells with expressions...", shouldn't it be "cons cells with s-expressions..."? – day Jun 13 '12 at 07:53
-
When you write, "expression-1 . expression-2", did you perhaps actually mean, .. s-expression-1 . s-expression-2 ? – Elliptical view Dec 08 '18 at 23:09
You should first understand main Lisp feature - program can be manipulated as data. Unlike other languages (like C or Java), where you write program by using special syntax ({
, }
, class
, define
, etc.), in Lisp you write code as (nested) lists (btw, this allows to express abstract syntactic trees directly). Once again: you write programs that look just like language's data structures.
When you talk about it as data, you call it "list", but when you talk about program code, you should better use term "s-expression". Thus, technically they are similar, but used in different contexts. The only real place where these terms are mixed is meta-programming (normally with macros).
Also note that s-expression may also consist of the only atom (like numbers, strings, etc.).

- 27,562
- 13
- 91
- 132
-
2s-expression is historically not program code, but a data notation. A list is a data structure. See McCarthy's original paper on Lisp. – Rainer Joswig May 27 '12 at 04:58
-
@RainerJoswig: as an example take a look at [mapcar](http://www.lispworks.com/documentation/lw50/CLHS/Body/f_mapc_.htm#mapcar) definition from CLHS - it says "mapcar operates on successive elements of the **lists**". Lists, not s-expressions. On other hand, you can rarely see phrase "interpreter evaluates this list...", in most cases you will see "interpreter evaluates s-expressions...". This is how they are used **now** in **popular literature**. Though (and I emphasized this) these terms are very similar and thus could interfere during long Lisp history, especially in scientific papers. – ffriend May 27 '12 at 14:24
-
@ffriend: sure, mapcar works on lists. No, eval does not work on s-expressions. It works on Lisp forms represented as data. – Rainer Joswig May 27 '12 at 15:01
-
@RainerJoswig: _data_ themselves can't _represent_ anything, by definition they are values of something and should themselves be represented somehow. In memory data about Lisp forms may be represented as nested Lisp's list, other kind of list (not used in this Lisp itself), set of Java class instances, hierarchy of algebraic data types in Haskell or anything. In _source code_ (and from the question it is clear that OP was confused about Lisp syntax) Lisp forms are _represented as text_, formatted as (having notation of) _s-expressions_. – ffriend May 27 '12 at 15:45
-
@ffriend: source code in Lisp are Lisp forms. Some of those have an external representation as text, some not. For example closures, streams, clos objects - they don't have an external representation. Still they can be part of Lisp forms, as data. – Rainer Joswig May 27 '12 at 17:37
-
@RainerJoswig: you misunderstand term "source code". Apart from some very low-level and exotic programming languages, you write programs by typing characters into ordinal text files. **Typed text** is what we call source code. And in Lisp this text has notation of s-expressions. This text is later transformed into Lisp forms by reader. But in text file it is just text in some notation, just like JSON or XML. – ffriend May 27 '12 at 18:12
-
-
@RainerJoswig: take a look at the definition of source code in Wikipedia. In Lisp _program_ is _represented_ the same way as the data it operates on in _source code_. But they may or may not have same representation internally - in memory Lisp code may be compiled and thus be represented as set of processor instructions, while data is represented as linked lists or other data structures. You ignore difference between source code (text), logical program (what programmer sees) and representation in memory, and thus also ignore context they create. – ffriend May 27 '12 at 21:15
-
@ffriend: Common Lisp ANSI Standard, Glossary, entry for source code: "source code, n., code representing objects suitable for evaluation (e.g., objects created by read, by macro expansion, or by compiler macro expansion)." Source file: "source file, n., a file which contains a textual representation of source code, that can be edited, loaded, or compiled." – Rainer Joswig May 27 '12 at 22:19
-
1@RainerJoswig: this is specific for Common Lisp only, but if you care, change every entry of "source code" to "source file" in my comments and you should get the idea. – ffriend May 27 '12 at 22:41
-
3The takeaway here, terminological nit-picking aside, is that the Lisp `eval` function does not operate on strings; in this it is different from the function of the same name in most modern dynamic languages. Instead, it expects its argument to already be the in-memory representation of the code, which is (a tree of hierarchically nested) lists. The *reader* transforms S-expressions into lists to be evaluated. So, S-expressions: textual representation of lists. Serialized, really, much the same way JSON or XML can represent an object tree. – Mark Reed May 30 '12 at 03:00
A simple definition for an S-expression is
(define S-expression?
(λ (object)
(or (atom? object) (list? object))))
;; Where atom? is:
(define atom?
(λ (object)
(and (not (pair? object)) (not (null? object)))))
;; And list? is:
(define list? (λ (object)
(let loop ((l1 object) (l2 object))
(if (pair? l1)
(let ((l1 (cdr l1)))
(cond ((eq? l1 l2) #f)
((pair? l1) (loop (cdr l1) (cdr l2)))
(else (null? l1))))
(null? l1)))))

- 32,179
- 12
- 66
- 85
Both are written in similar way: (blah blah blah), may be nested. with one difference - lists are prefixed with apostrophe.
On evaluation:
- S-expression returns some result (may be an atom or list or nil or whatever)
- Lists return Lists
If we need, we can convert lists to s-exp and vice versa.
- (eval '(blah blah blah)) => list is treated as an s-exp and a result is returned.
- (quote (blah blah blah)) => sexp is converted to list and the list is returned without evaluating
IAS:
- If a List is treated as data it is called List, if it is treated as code it is called s-exp.

- 2,313
- 2
- 28
- 31
-
"If a List is treated as data it is called List, if it is treated as code it is called s-exp." IME, if a list is treated as data it's called a list, otherwise it's called whatever it is - usually a function call. The term `s-expression` is reserved for talking specifically about the syntax in a metatextual way. – Mark Reed May 30 '12 at 03:02
-