What is the point of this genealogy? What makes a language a Lisp is (i) natural and practical homoiconicity with sexps, (ii) automatic memory management and (iii) advanced interactive development features, including the REPL, the image, restarts and hot code loading. These are the features that distinguish it and make it an advanced tool. (i) is quite particular to it, (ii) is invented for it and (iii) is a big part of the power, and for me, Lisp means a language that has (i), (ii) and (iii) in one package. Otherwise whether or not it include code from Lisp 1.5 or allow effortless porting is not all that important. For the latter, most compilers are cross-platform anyways, so one can just grab a suitable binary tarball and get going.

Clojure fails at (iii), as it just propagates Java exceptions, but I don't think that is impossible to fix, so not a fundamental flaw. JVM is too heavy, and that is a problem for some. Otherwise, it's a well thought-out Lisp with a thriving community and some cool guys and a BDFL (i.e. Hickey).

Common Lisp excels at all the three of the items I listed, plus it's batteries included and has lots of libraries around. Also, it has a standard, so that you can develop on SBCL and deploy with Clozure CL or CMU CL. It's downside is there's some historical baggage and there are no DHH or Hickey or Torvalds in the community, which isn't a downside for me, even an upside.

Those aren't what make a language a Lisp. There are Lisps without Automatic Memory Management, there are Lisps without restarts or images (although hot code loading is fairly common, and I've never seen a Lisp without a repl). Homoiconic expressions are an important part of it, but there are many lisps without macro systems.

I'm a Schemer, and Scheme IS a lisp: we don't have restarts, but we do have call/cc, and images as Lisp has them are an optimization hack in any case. And we're finally getting some well supported implementations. Yes, we have hot code loading in most implementations.

Come to the dark side, we have (lexical) cookies (encoded with the current continuation after baking, of course).

What I list is why I highly esteem lisp. I can't see ho it's advantageous to use without them.

...Well, then, maybe cast your net a bit wider? There are plenty of other reasons to use lisps.

Clojure has a primitive repl by default with lots of Java shining through. It has no image dumping. No restarts. Hot code loading is limited. Clojure even has no interpreter.

Need I mention that Lisp 1.5 had no restarts, and that image dumps are primarily a hack, and not at the core of lisp by a long shot?

Images are not a hack. They allow us to save the state of a program and use it later. My Lisp Machine at home would not even work without it. It's the software the machine boots into.

Image dumps are also a useful way to create applications or use pre-assembled program state during development. Makes faster startup times, than loading objects during start each time.

Even an editor like GNU Emacs boots up a Lisp image. Which makes it much faster than loading code at start.

They're an optimization in most dialects that support it: it's not like Smalltalk, where you can reload your app state and continue exactly where you left off.

Smalltalk doesn't do that and if it does, it's because the runtime is dumb. For example, a Smalltalk which saves and restores threads in an image, can only do that, because it does not use native threads. Various Lisp systems are using native threads. If a Smalltalk image starts, formerly open files may be opened again. If the files is not there, then nothing happens. Same for network connections.

I would be very irritated if my Lisp Machine on start would reopen all network connections... But it has a controlled restart process, where I tell Lisp what to restart on a reboot. Actually a Lisp Machine has a list in memory, where the restart tasks are kept. If the image is restarted, one of the tasks it does is to go through this list and execute the various restart tasks...

I don't know all of smalltalk's semantics for transient connections: However, when a smalltalk image is shut down, a snapshot of all objects in a live system are kept. I would assume that the VM signals a shutdown, and that would tell all the transient entities to close themselves.

Anyways, Lisp images don't work like that: a lisp image is a static preloaded environment. If you redefine some functions, exit lisp, and reopen the interpreter, those redefinitions won't be there.

Why would you exit? On a Lisp Machine you can make the image and continue working. It also has incremental images, etc.

If I save and load an image, the new definitions are still there.

What you refer to has very little to do with imags, Smalltalk keeps a database of code in files under system control. That's also how Interlisp worked.

On a Symbolics Lisp Machine I would configure the machine, load my software and create an image. After starting that image I would on login load any changes from the code bases. If this would be too long, I would save an incremental image.

The Lisp Machine had many more image related features...

Well, on a lispm, yes. However, most of us don't have lispms (as much as we might want one!), and the symbolics VM is a pain to run. In CL, you don't do that sort of thing.

In any case, at least a few Schemes have images, so it's a moot point in that debate. It's still interesting, though.

> In CL, you don't do that sort of thing

Oh, something like LispWorks has extensive support for using images, too. It has a very extensive application/library delivery mechanism based on images.

LispWorks can also save 'sessions', even automatically as periodically timed events. Even without quitting Lisp. Sessions are basically IDE states (files, listener history, lisp image, windows, ...).

Most of those things appear in scheme. Slightly different naming, but the same, more or less.

To say that there's compatability between Scheme and CL, and no compatability with Racket is ridiculus: Racket has Scheme compatability modes.

As for the language being called Lisp if it's Lisp, two of the examples you list in the "non lisp" category do so: Clojure's website claims it is a "dialect of lisp," and AIM-349 describes scheme as "essentially a full-funarg LISP."

As make no mistake, all of these languages, from Common Lisp to Clojure to Scheme, are dialects. They have the same origins, and they share many of the same ideas.

> AIM-349 describes scheme as "essentially a full-funarg LISP

That's long ago. That was kind of true in the mid 70s.

> and no compatability with Racket is ridiculus

CL has no Racket compatibility. Zero. Racket has no CL compatibility. Zero. Porting programs is a full rewrite.

> Clojure's website claims it is a "dialect of lisp,"

Best it is a new language, derived from Lisp and influenced by C++, C#, Common Lisp, Erlang, Haskell, Mathematica, ML, Prolog, Scheme, Java, Racket, Ruby.

'Dialect' in this case is the euphemism for 'fully incompatible' with 'random operator renames and shuffling functionality' where it kind of looked compatible.

> As make no mistake, all of these languages, from Common Lisp to Clojure to Scheme, are dialects.

Sure, but not of Lisp. Of those three, only Common Lisp is a Lisp dialect.

> They have the same origins, and they share many of the same ideas.

Less and less. As a starter: Clojure has no Lisp lists as basic data structure.

So scheme WAS a lisp, and now isn't? What changed that makes you think that?

And it had better not be nil/false equality. Even McCarthy says that was, if not a mistake, then an accident.

As for Clojure not having Lisp lists, its list implementation is... eccentric, but it DOES have lists.

Actually, scratch that, its list implementation, from a Lisp perspective is broken. Psychotically broken. But it DOES have one. Even if it's insane. What, will you say the same about newlisp lists?

For that matter, is Picolisp a Lisp?

> So scheme WAS a lisp, and now isn't?

EINE: Eine is not Emacs.

ZWEI: Zwei was Eine, Initially.

And, thus:

SWALANI: Swalani Was A Lisp, And Now Isn't.

A dialect waiting to be invented.

:)

What might be a recursive acronym for Scheme, though?

Oh, oh ... I just got one:

"Scheme Crams Hygiene into Every Macro Expansion."

It doesn't, for the record. Not any implementation that you'd use.

The acronym's good though, I just didn't want anybody else thinking that was true, given how many people already do.

> What changed that makes you think that?

R6RS

> As for Clojure not having Lisp lists, its list implementation is... eccentric, but it DOES have lists.

Lazy persistent sequences is the basic abstraction.

Uggghh. R6RS was an absolute mess. But I'd still say it was a lisp.

Have you looked at R7RS, the latest spec, that goes back to the drawing board on a lot of the stuff R6RS did?