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))))))))

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)

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.

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)))))

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.

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?

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.

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.)

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

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

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.

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.

Wikipedia [0]:

> Scheme is a functional programming language and one of the two main dialects of the programming language Lisp.

[0]: https://en.wikipedia.org/wiki/Scheme_%28programming_language...

> The "Lisp" Scheme is a dialect of is no longer the current meaning of "Lisp". It is somewhat like calling English a dialect of German because of ancient history that has since between invalidated by each of their separate evolution, Fahrvergnügen, Weltanschauung, Kindergarten, and Pennsylvania to the contrary notwithstanding. There is also a very limited value in talking about "Germanic languages" in terms of your actual ability to use any of the Germanic languags. You do not order the "vertebrate" in a restaurant, but generally choose between fish or bird or meat. In other words, there is a time when an abstraction and a commonality has completely ceased to be valuable.

[0] http://www.xach.com/naggum/articles/3224964049435643@naggum....

It expresses pretty much all of the core principals of a LISP. If it looks like a LISP, thinks like a LISP, behaves like a LISP; then do you really gain anything by trying to separate from other LISPs?

Or less extremely, why don't we consider Python and Ruby to be the same family, or Java and C#? Those pairs are arguably more similar than the pair of Common Lisp and Scheme.

The dialects of Dutch in Belgium contain completely different words and phrases - but the core is still Dutch.

But for large parts of the speech they are recognisably similar.

So I'd say yes all the lisps you mentioned are dialects of Lisp. You can't run one directly in the other, but they are reconisably similar programming constructs.

Referring to the broad Algol-family isn't uncommon (well, at least, I do it quite a bit.)

> Or less extremely, why don't we consider Python and Ruby to be the same family, or Java and C#? Those pairs are arguably more similar than the pair of Common Lisp and Scheme.

Java and C# are frequently described as being part of a single close language family (much closer than the broad Algol-family; sometimes in an intermediate-breadth family that also includes ), and Ruby and Python are much less similar than Scheme and Common Lisp.

We sometimes do though, don't we? Not that terminology, but I often see the people talking about "curly brace languages" or "C/C++/Java/C#".

Edit: In hindsight at the end of the day I should have been more careful with the "Scheme is not Lisp" (at least I didn't say "Scheme is not a Lisp") comment...I'm only continuing these threads because I read the original submission pretty close to when it was posted and back then I only knew a bit of SICP, tried enough Lisp to duplicate some SICP examples, and was frustrated with the Lisp-2 syntax along with what I perceived as a REPL freakout on any error so I put Lisp aside. It would have been helpful for someone to tell me "Scheme is not Lisp" back then and get me to actually explore all that Common Lisp has to offer.