I mean Scheme is not Common Lisp, and Common Lisp is Lisp. Both are "a Lisp" (as is Clojure), or perhaps "a dialect of Lisp", but it's questionable if that really means anything beyond s-exps and macros.

Why does Common Lisp get the distinction of being the "true Lisp" and not Scheme? Scheme precedes Common Lisp by almost a decade

This Lisp I code is from 1959/60.

http://bitsavers.informatik.uni-stuttgart.de/pdf/mit/rle_lis...

Page 101:

    DEFINE
    (((COLLAPSE,(LAMBDA,(L),(COND,((ATOM,L),(CONS,L,NIL)),
    ((NULL,(CDR,L)),(COND,((ATOM,(CAR,L)),L),(T,(COLLAPSE,
    (CAR,L))))),(T,(APPEND,(COLLAPSE,(CAR,L)),(COLLAPSE,(CDR,L))))))))

This is the Common Lisp version. Formatted, comma removed, DEFUN instead of DEFINE.

Other than that the code is unchanged. It still works in Common Lisp.

    (DEFUN COLLAPSE (L)
      (COND ((ATOM L) (CONS L NIL))
            ((NULL (CDR L))
             (COND ((ATOM (CAR L)) L)
                   (T (COLLAPSE (CAR L)))))
            (T (APPEND (COLLAPSE (CAR L)) (COLLAPSE (CDR L))))))

    CL-USER 191 > (collapse '(1 2 (3 4) ((5 6) 7)))
    (1 2 3 4 5 6 7)

Common Lisp is backwards compatible to Lisp I and Lisp 1.5 in many ways.

Code like that can be relatively easy ported to Scheme (naming and syntax is slightly different). There are examples which are more difficult. But generally simple (!) Scheme is not that far away from that old core.

Naggum has a pretty good answer for that, linked in the other comment branch: http://www.xach.com/naggum/articles/3224964049435643@naggum.... You could also argue based on things like Common Lisp can run LISP code from 1960 with a very small driver, or the general history of code porting and sharing, as done here: https://news.ycombinator.com/item?id=9387131#9404543

I read that answer, I didn't find it helpful on two points.

1. There's this really nice analogy about German and English languages, but it doesn't have any specifics. In particular, the crux of his entire argument is in this statement

> The two languages and their attendant communities have drifted so far apart that there is nothing of value in their intersection.

Which he simply states as fact without any sort of follow up or justification. And I disagree. Consider this Common Lisp snippet from Wikipedia computing the answer to the birthday paradox:

  (defconstant +year-size+ 365)

  (defun birthday-paradox (probability number-of-people)
  (let ((new-probability (* (/ (- +year-size+ number-of-people)
                               +year-size+)
                            probability)))
    (if (< new-probability 0.5)
        (1+ number-of-people)
        (birthday-paradox new-probability (1+ number-of-
  people)))))

Literally replace "defconstant" with "define" and "defun birthday-paradox (probability number-of-people)" with "define (birthday-paradox probability number-of-people)" and that's valid Scheme.

I'll readily admit they are two different languages, but pretending they are as different as C and Python or something is absurd.

2. Even if you convince me these two languages are so different, there's nothing here to convince me Common Lisp deserves the title of the "real Lisp" or "true Lisp". Scheme can also run LISP code from 1960 with a very small driver.

Is it that absurd? Where is Scheme's CLOS, condition system, built-in debugging framework, and batteries-included standard library? Type declarations? Dynamic scoping? Multi-methods?

Maybe Racket (or Chicken or Chez or Guile or...) has all of these things, Racket is pretty awesome, but those things aren't standardized, whereas I can get those things in Lisp regardless of if I use SBCL/Clozure/clisp/etc. Maybe it's closer to the difference between C (with a bunch of different compiler extensions) and C++ than C and Python, but it's a pretty big difference.

Ultimately I think the claim of Common Lisp being the "true Lisp" is simply that deciding such a thing was the whole point of Common Lisp. Without a standard, you're left with someone writing http://wiki.call-cc.org/eggref/4/multi-methods#examples (or http://wiki.call-cc.org/eggref/4/fast-generic) and someone else writing https://docs.racket-lang.org/multimethod/index.html and neither being able to share code with each other. Most code isn't as trivial as the birthday paradox.

Would you want to try writing a (R6RS) Scheme driver for that 1960 code and see how straightforward it is?

Where do you slot https://en.wikipedia.org/wiki/Dylan_(programming_language) ? Should it be in the running for "the true Lisp"? If not why not?

I agree they are pretty different languages, and you give some solid points as to why: CLOS, dynamic scoping, multi-methods, etc. My point was your link mentioned exactly none of those examples, in fact gave no examples at all, and so wasn't very convincing.

The second point that the argument that Common Lisp is the "true Lisp" because that's why it was made is a faulty syllogism. Just because that was their goal of creating Common Lisp doesn't necessarily mean that is the case.

And Common Lisp isn't the only language with a standard: Scheme had an IEEE standard less than a year after ANSI Common Lisp, and has several RnRS updates since then.

Long story short, I don't think any language should be considered the "true Lisp". Maybe the original Lisp, but even then only as a technicality. And trying to declare a language as the "true Lisp" comes off as a little insulting to related languages and a little bit arrogant. It implies, to a certain degree, that you look down on other languages as lesser, inferior, failed attempts to reach the true zen of Lisp. I'm sure you didn't mean it that way, but as a fan of Scheme (and Common Lisp too!) it reads that way.

Maybe there's no platonic ideal Lisp, and that's the problem, since the thing that makes programmers feel good is some vague sense that there is such an ideal. A sort of god. ;) On the level of communication and definitions though, it seems totally reasonable to me that if your goal as a community of all sorts of versions/dialects of Lisp is to unify into one standard, then you get to call your new unification the Lisp.

I see your point about arrogance, though I think the insulting tone could be turned around easily -- you have these Lisp-like languages that don't even have Lisp in their name nor a lot of Lisp's crucial features trying to appropriate/claim an inheritance on all the hard work and glory and name recognition that went into Common Lisp and its predecessors. Let them have their name. I'm a pretty big fan of Clojure (and do like what Racket is doing when I read up about it) but imagine trying to sell Clojure to an old Lisp hand with "it's like Lisp" and watching them type (inc "a") vs (1+ "a"). https://pastebin.com/kBfNvxei vs https://pastebin.com/hPB2cy1X and there's no contest. (You might win them over with further persistence but they'll probably be wondering where all their favorite parts about Lisp are in this so-called Lisp-like.)

>Is it that absurd? Where is Scheme's CLOS, condition system, built-in debugging framework, and batteries-included standard library? Type declarations? Dynamic scoping? Multi-methods?

Does Lisp from 1960 have these things? Then I guess it isn't really Lisp?

How I see it, Lisp 1.5 was Lisp, but as time went on and many 'versions' of Lisp for different systems with different capabilities came into being, there was no longer really a singular Lisp. Then there was a great unification that spit out Common Lisp, and that became Lisp. So if Lisp 1.5 was released today as something new, it wouldn't be Lisp, but merely another Lisp-like. It's too different. No one today thinks that if you drop "Lisp" in a conversation you really mean Lisp 1.5. (Maybe if you write it as LISP...) It's either going to mean Common Lisp, or maybe a reference to the vague Lisp Family. I don't think Lisp will ever be synonymous with "Scheme".

Maybe you'd appreciate some Lisp history, to also answer your question about "what other dialect[s]"?

http://www.paulgraham.com/thist.html

http://lispm.de/30ycltl

I do know some of the history. I was just asking those questions as a challenge. Regarding the question of the other dialect, the parent used the term as a way of distancing Scheme from what I assume is the one true Lisp: Common Lisp. But the point the passage they had an issue with noted two dialects. The other, of course, being that one true Lisp.

The way I see it, the things that make Lisp "Lisp" are not exclusive to either one. One might say that the intersecting characteristics aren't interesting, but these characteristics are what Lisp is truly about.

SML and Caml are both ML. Haskell 98 and Glasgow Haskell are both Haskell. Dyalog APL and APL2 are both APL. And so on.

He was just giving those as examples of ways in which Scheme and Common Lisp differ. Which is a fair point. Of course it does raise the question: are those features essential attributes of the Platonic ideal that is True Lisp, or simply nice addons Common Lisp provides?

Yeah, that's what I was getting at.

No, but the Common Lisp of 1984 has much of the Lisp of 1960. It's backwards compatible in many ways.

> Even if you convince me these two languages are so different, there's nothing here to convince me Common Lisp deserves the title of the "real Lisp" or "true Lisp"

It's the lineage of Lisps where Common Lisp is in, which is Lisp:

Lisp I, Lisp 1.5, Standard Lisp, Interlisp, Maclisp, New Implementation of Lisp, ZetaLisp, Spice Lisp, Common Lisp, Emacs Lisp, ISLisp, ...

Those are all compatible to some extent and share a common core. Code moved a lot along these dialects. Macsyma had been written in Maclisp, moved to Zetalisp, then to Common Lisp. Reduce was written in Standard Lisp and then was ported to Common Lisp (without adoption). Hemlock was written in Spice Lisp and moved to Common Lisp. LOOPS was written in Interlisp and then moved to Zetalisp and later Common Lisp. CLOS was written in Common Lisp and was moved to Emacs Lisp and ISLisp. Even much of Common Lisp was moved to Emacs Lisp. ISLisp can be implemented as a package in Common Lisp relatively easily (Kent Pitman did this to check that ISLisp is compatible and has nothing which is not 'easily' implementable).

It was also usual that some Lisp implementations ran multiple Lisp dialects side by side, sharing everything: data, memory, I/O, ... For example Interlisp-D had a Common Lisp implementation side-by-side with Interlisp. The Symbolics Lisp Machine ran Zetalisp and four variants of Common Lisp side-by-side.

Then there are a lot of derived languages which either have different syntax, different semantics, different data structures, etc.

Examples are Logo, MDL, Scheme, Racket, Dylan, ML, Clojure, Javascript and a bunch of other languages.

Scheme initially shared some code with Lisp. Dylan tried it with a Lisp transpiler, ML initially was written in Lisp, ...

> Scheme can also run LISP code from 1960 with a very small driver.

The old Scheme is relatively near the Lisp mainstream, the newer Scheme less and less. Twenty years ago there was some code sharing between Lisp and Scheme, now almost none.

For me there are two definitions of Lisp:

* the main line compatible and sharing Lisps

* the general abstract family of Lisp which share an undefine subset of a set of features: lists, s-expressions, lambdas, parentheses, ... But you can find lots of languages in the larger Lisp family which have only a rough subset of this, like Javascript or Logo.

So when somebody says "I am going to write some Lisp now", in your mind they are always going to write Common Lisp?

I'm guessing the latter.