Cons cells are not the important point--at least not for me. The important point in this context is that expressions are represented by something better (that is, more conveniently-structured) than flat text strings, and that the representation be a standard data structure in the language, and that operations on source code are implemented by APIs that are exposed as standard parts of the language.

As far as I'm concerned, if a language does that, then it's nailed this particular part of being Lispy. There are some other parts, but that discussion is outside the scope of this one.

It's not completely irrelevant, since Common Lisp has the idea of a text-based file with source code and a compilation mode for it (-> COMPILE-FILE).

But generally what you say is true. We see that especially in two places: 1) the Lisp interpreter, which runs non-text s-expressions and 2) special development environments, like Interlisp-D/Medley where a prominent way to edit Lisp code is a structure editor, which manipulates s-expressions in memory.

So it's like generating JS code text from JS, but working with JS code as a text is much more confusing compared to working with lisp code as a list.

The name LISP derives from "LISt Processing". Linked lists are one of Lisp languages' major data structures, and Lisp source code is itself made up of lists. As a result, Lisp programs can manipulate source code as a data structure, giving rise to the macro systems that allow programmers to create new syntax or even new domain-specific programming languages embedded in Lisp.

It also lists the following under "Syntax and semantics":

    Symbolic expressions           — Check
    Lists                          — Check
    Operators                      — Check
    Lambda expressions             — Check
    Atoms                          — Check
    Conses and lists               — Nope (not linked lists)
    S-expressions represent lists  — Nope
    List-processing procedures     — Check
    Shared structure               — Nope (not linked lists)
    Self-evaluating forms and quoting — Nope
    Scope and closure              — Kinda
    List structure of program code — Nope
    Evaluation and the Read-Eval-Print Loop — Nope
    Control structures             — Nope

I'm not sure I agree. Sure, in most dialects you are given access to Arrays, Classes, and other types that are well used. And you can choose to avoid lists, just like you can avoid using dictionaries in Python, and Lua. But I find that the cons cell is used rather commonly in standard Lisp code.

The very idea "to implement a List" in what is supposed to be called a Lisp is.. well, I do respect the amount of work that has been done, but.

Such kind of confusion, it seems, comes from a wrong perspective of what a Lisp is. Let's look first at what it is not.

It is not some "modern OO" language with parenthesized prefix notation, it could be so boring. Second, a List is not some "data structure in Lisp", it is the most important, non-separable fundamental feature of the language. Without "native conses" a Lisp is nonsense.

The explanations is going to grow lengthy, but it worth a try.

A Lisp is a set of layered DSLs and ADTs. Its "miracle" in what it is small and good-enough, in accordance with "Less is more" maxima.

There is no fucking "Class Node" in what a List is. It is just (cons 1 (cons 2 (cons 3 '()))) or 1:2:3:[] if you wish.

The big ideas is to separate clearly the use from the implementation, which is called an Abstraction Barrier.

A complete definition of the basic building block - a cons cell, or the Pair ADT is cons, car, cdr, pair? and nil while a List is just one more "constructor" - list. This is minimal and it is good-enough.

It is so "good" that it "created" another small miracle - cadr/cddr notation, which is just an accidental piece of beauty created by a human mind (like a Lisp itself). Only complete tasteless person could abandon this in order to use dull and mediocre first/rest or any other names for selectors that doesn't "chain" and reflect the notion that almost everything could be made out of conses.

The problem is that we have way too many of those who cannot grasp the beauty of what a cadr or cddr is.

Implementation in a language's runtime is quite another topic. There we probably should have a notion of a pool-based allocation (in order to not call malloc for each cons) and locality (to properly implement persistence) etc. but these implementation specific things must never leak int "high-level" use. Again, there is no fucking Class Node.

Speaking of Lisp apart form Lists is like speaking of water apart from the waves. Water has waves, Lisp has Lists in its own nature.

Giving this nature of Lists we could have a general mapper procedure, or map. The idea of a Functor from Math (or these control abstractions from Haskell) has nothing to do with it. It is just the recursive nature of List's structure allows us to define recursive processes.

Even trees not necessarily must have any Class Node. Here is a classic example:

   (define make-tree cons)
   (define datum car)
   (define children cdr)
   (define (leaf? n)
      (null? (children n)))

   (define (tree-map fn tree)
      (make-tree (fn (datum tree))
	     (map (lambda (ts) (tree-map fn ts))
		  (children tree))))

Last but not least. This very site is build in a dialect of Lisp which never tries to redefine what a List is.

More about Lisps - http://karma-engineering.com/lab/wiki/Bootstraping

More about piling up useless abstractions - http://karma-engineering.com/lab/wiki/Monads

If you find real LISP code unreadable because it doesn't look like javascript - because you can't tell when your sequence is a linked list or an array when there's no curly braces - I suggest learning to read and write LISP code and understand how LISP works. A real LISP I mean, not clojure.

Again, other LISPs have data structures aren't from linked list. A complete myth that that they only use linked lists.

Anyway, even saying "code is linked list" does not really cut it as you can represent 'ordinary' programming language program as a list of tokens. What makes LISP special is that code is a first class citizen and the mapping between code you edit and the programs run-time memory representation is trivial. Combined, you get this special feeling that "code is data".

One of my main gripes with Common Lisp is its complexity. When I started learning Lisp, I expected to find a beautiful and elegant language, one without a need for syntax. The way C is almost an elegant assembly. Maybe I should have tried Scheme instead.

Common Lisp is anything but elegant. Instead of a regular syntax, you get all these "mini-languages", like the format syntax e.g.

    (format t "~{~a~^, ~}" '(1 2 3))
    ; prints out
    ; 1, 2, 3

The loop macro is also quite powerful and complicated. e.g.

    (loop :for i :from 1 :to 1000 :collect (* i i))

The fact that Common Lisp is a Lisp-2 makes treating functions as first-class as rather awkward. I could never remember when I needed to prepend a lambda with #'.

This article may be of interest http://xahlee.info/comp/Common_Lisp_quotations.html

I found much of the elegance I was expecting in Haskell. But maybe Scheme is a better lisp.

There are different "schools" now. Some argue that representing the program only with lists is more uniform and simple. Rich Hickey argues that the different multiple usages of lists in "traditional" lisps, such as in Common Lisp, imposes a cognitive burden so increase the complexity.

The Janet language for example follows Clojure whereas as Racket is still a modern language but follows the "tradition".

'(GRAPH-EDGE <source-vertex> <target-vertex>)

whereas in ML you would write

type edge = { source: Vertex.t; target: Vertex.t }

which is not a list, but an entirely different representation. In Common Lisp the representation could of course be a CLOS object or a DEFSTRUCT (I think, my CL-fu is definitely not that good).

As for the composition, lisps are lacking (nice) currying which is one of the basic building blocks when constructing combinator-libraries.

Contrasted with many other languages that are catching up, but sometimes have surprising amount of boilerplate to process data.

Objects aren't compound values. Objects are compound, well, objects. And pointers to objects are primitive, indivisible values - not compound!

> lists

Racket and ML have lists. Lisp has mutable linked data structures, built out of `cons` cells, whose value at any given point in time may be a list. But the value itself isn't first-class, because you can only bind the identity of the cons cell to a variable.

That's not true. Every modern Lisp implementation has many primitive data structures: vectors, hash tables, etc.