> Compatibility: Unless there is a good reason to the contrary, Common Lisp strives to be compatible with Lisp Machine Lisp, MacLisp, and Interlisp, roughly in that order.
Zetalisp is a Maclisp dialect. The is basically very little compatibility to Interlisp. This leaves us with Zetalisp as its main predecessor.
When CL was designed, Zetalisp, NIL, Spice Lisp and S-1 Lisp (the ones mentioned mostly in the CL history) were active implementations. They are now forgotton, because they were superseded with a language directly based on their heritage or, in the case of Spice Lisp, they are now actually Common Lisp.
If you actually look at Zetalisp, the main predecessor, it was actually as large or even larger than Common Lisp - and Common Lisp looks larger, because the language includes part of a library and it was documented in more detail than other Lisp languages.
> it looks like Lisp
But it does not run ANY prior Lisp application and basically no substantial, beyond (+ 1 2), Lisp application can run in Clojure without being rewritten. Not ported. Rewritten. Clojure does not have any compatibility to the Lisp from McCarthy - not in the language itself and not even as a compatibility layer. It does not have most of its functions and if the functions have the same name, they mostly do something different. Even if you look at basic numerics, it does not do what one would expect from a Lisp, but uses the host language semantics (Java/JVM, Javascript, ...).
It's base data structure is not the linked list, like every other Lisp dialect.
A sheep has four legs, but it is still not considered to be a dog - it can't even bark.
For me the general concept of being a Lisp is so vague, that I prefer a more strict definition: a language and its successors which strive to be compatible in syntax, semantics, pragmatics and community.
If we take being a Lisp in a broad meaning, then it includes languages like Logo, Dylan, maybe even ECMAscript/Javascript. Which makes it a meaningless term, IMHO. Sure it make you sometimes feel well to be included in a family - but often enough this sets expectations which can not be fulfilled: like reading a Lisp book and then trying the example code in those languages - and then it does not work...
CL is a specific branch of the Lisp tree. Clojure is a new tree, based on roots in Java (runtime and interop), Lisp (various ideas, like expressions, macros, ...), FPLs (ideas like 'persistent' data structures, ...
> like reading a Lisp book and then trying the example code in those languages - and then it does not work...
Does SICP work in Common Lisp these days? Or is Scheme also not sufficiently a lisp?
> CL is a specific branch of the Lisp tree. Clojure is a new tree, based on roots in Java (runtime and interop), Lisp (various ideas, like expressions, macros, ...), FPLs (ideas like 'persistent' data structures, ...
I would definitely agree with this.
EDIT: It occurs to me that maybe the difference of opinion is around the whole acceptance of the notion of lisp as a family vs. Capital Lisp as a species.
It seems like the idea of strict compatibility with Common Lisp is more akin to the definition of a species (i.e. more or less able to interbreed). On the other hand, if one accepts the premise that lisp can be a family, then incompatible evolutionary changes should be expected.
Whether one considers Clojure a lisp probably depends on whether they think it bears sufficient resemblance to other accepted lisps as to constitute a family. Lions and house cats are pretty different and aren't biologically compatible from a reproductive standpoint, but share a lot in common such as a similar morphology and common ancestor. Common ancestor is a sticky point, because presumably some Common Lisp implementations don't literally share code with prior lisps... A clean room Common Lisp couldn't meet that standard, for example.
With a few macros and compatibility functions there is not much in SICP Scheme which does not work in similar ways in Common Lisp. SICP is using a rather primitive version of Scheme - which actually does not even run in newer Scheme dialects without changes.
SICP does not even use macros. Later Scheme languages diverge much more and thus form their own language family. There is still a core in Scheme, which is relatively close to Lisp.
You can see that CL uses two namespaces and some of the operators are named differently (like EQ in Lisp and EQ? in Scheme, SETQ in Lisp and set! in Scheme).
But beyond that and even without a compatibility layer, the SICP code has 1 to 1 direct equivalents in CL: function definition, s-expressions, local functions, local lexical variables, setting variables, creating cons cells, testing for a NIL value, symbols, equivalence of symbols, raising an error, cond operator, ....
OTOH if you look at Clojure, it lacks the basic cons cell data structure and then one needs to use operators from a different data structure. LET / SET! does something else in Clojure - reading the documentation about that is confusing enough.
> A clean room Common Lisp couldn't meet that standard, for example.
It's not about that an implementation actually uses code from others (though it might), it is about actually being able to run Lisp applications/libraries or have them ported without the need to rewrite them.
Take for example Macsyma. It has its roots in mathematics code written in Lisp in the 60s. It was then further developed in Maclisp. It was then ported to Zetalisp and Franz Lisp (IIRC). Then it was ported to Common Lisp and still runs in various Common Lisp implementations. I have myself ported it to a Common Lisp implementation it never ran before in a day. This is an example of a substantial and non-trivial Lisp program which didn't need to be reimplemented, since it has been moved to new Lisp dialects to be able to be run on current hardware. A version of it now runs on Android devices...
The LOOP macro was actually maintained at MIT as a single file for multiple Lisp dialects for some time.
You can take a Lisp book from the 60s and run its examples in CL without effort. There is code from McCarthy from 1960 which runs mostly unchanged today, with a minimal compatibility layer. You can't run anything from McCarthy in Clojure because it lacks the most basic things like cons cells. All the list processing stuff needs to be rewritten to fit into Clojure's idea for 'persistent sequences' or other concepts.
https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node6.html#SE...
> Compatibility: Unless there is a good reason to the contrary, Common Lisp strives to be compatible with Lisp Machine Lisp, MacLisp, and Interlisp, roughly in that order.
Zetalisp is a Maclisp dialect. The is basically very little compatibility to Interlisp. This leaves us with Zetalisp as its main predecessor.
When CL was designed, Zetalisp, NIL, Spice Lisp and S-1 Lisp (the ones mentioned mostly in the CL history) were active implementations. They are now forgotton, because they were superseded with a language directly based on their heritage or, in the case of Spice Lisp, they are now actually Common Lisp.
If you actually look at Zetalisp, the main predecessor, it was actually as large or even larger than Common Lisp - and Common Lisp looks larger, because the language includes part of a library and it was documented in more detail than other Lisp languages.
> it looks like Lisp
But it does not run ANY prior Lisp application and basically no substantial, beyond (+ 1 2), Lisp application can run in Clojure without being rewritten. Not ported. Rewritten. Clojure does not have any compatibility to the Lisp from McCarthy - not in the language itself and not even as a compatibility layer. It does not have most of its functions and if the functions have the same name, they mostly do something different. Even if you look at basic numerics, it does not do what one would expect from a Lisp, but uses the host language semantics (Java/JVM, Javascript, ...).
It's base data structure is not the linked list, like every other Lisp dialect.
A sheep has four legs, but it is still not considered to be a dog - it can't even bark.
For me the general concept of being a Lisp is so vague, that I prefer a more strict definition: a language and its successors which strive to be compatible in syntax, semantics, pragmatics and community.
If we take being a Lisp in a broad meaning, then it includes languages like Logo, Dylan, maybe even ECMAscript/Javascript. Which makes it a meaningless term, IMHO. Sure it make you sometimes feel well to be included in a family - but often enough this sets expectations which can not be fulfilled: like reading a Lisp book and then trying the example code in those languages - and then it does not work...
CL is a specific branch of the Lisp tree. Clojure is a new tree, based on roots in Java (runtime and interop), Lisp (various ideas, like expressions, macros, ...), FPLs (ideas like 'persistent' data structures, ...