The term ''modern clean Lisp'' refers to any number of post-CommonLisp, post-SchemeLanguage dialects of LispLanguage that claim to correct (perceived) flaws of the two predominant Lisp dialects - namely, the sheer size of CommonLisp (and its numerous backwards-compatibility kludges), and the "academic" nature and lack of good libraries of SchemeLanguage. (Note. I said "perceived"; I offer no comment here on whether those perceptions are valid or not).

ModernCleanLisp''''''s are not backwards-compatible with either CommonLisp or SchemeLanguage - code written for either CL or Scheme won't (in general) run on a ModernCleanLisp without modification. However, MCL's do have much in common with Lisp - EssExpressions, a heavy focus on lists as a predominant data structure, homoiconicity [HomoiconicLanguages], a good macro system, etc. Some of the more esoteric or difficult features of Scheme or CL are frequently left out - FirstClassContinuation''''''s, for instance.

Some LISPers think these projects are a waste of time, that efforts to improve Lisp should focus on improving CL or scheme, rather than starting over. Others claim that CL and Scheme have too many backwards-compatibility issues (and too many divergent implementations), and that in the long run it's better to start fresh. (Of course, many fans of CommonLisp seem to think that even Scheme should go away...)

''Well, some lispers believe any old stupid thing; diversity of opinion is vital and expected in the Lisp community. But a serious and reasonable critique you'll see is whether a given ModernCleanLisp makes unnecessary mistakes which previous lisps avoided. After all, a programming language is just a program.''

Examples of ModernCleanLisp''''''s:

* GooLanguage
* DoubleYouSeven
* ArcLanguage
* KernelLanguage

Examples of NewOldFashionedLisp''''''s NewWeirdLisp''''''s
* NewLisp (weird blend of all kinds of Lisp functionality)
* PicoLisp (dynamic binding, no lexical binding - do I need to say more?)

In addition, some might consider DylanLanguage to be an MCL as well; though it wasn't derived with that in mind and it replaces sexprs with an Algol-like syntax. (Strip off the outer coat of paint, and there's a good chunk of CommonLisp staring you in the face).

----
Unfortunately they add other mistakes which don't make them clean or even modern. Creating a real ModernCleanLisp has been tried a few times. All failed. See: EuLisp, ISLisp, prefix-Dylan, and some more ... If you want a modern clean Lisp you can just take EuLisp. The definition and some implementations are there. Almost nobody uses them. So, don't hold your breath - it will not happen anytime soon. And, no, ArcLanguage isn't it. The thing is, Common Lisp and Scheme are good enough for Lisp programmers. The newer Lisps aren't getting wide acceptance and aren't getting any acceptance from non-Lisp-programmers. See ModernCleanLisp as experimental languages that will die away after some time. CommonLisp and Scheme will stay.

''I hate everything but lisp, including lisps that aren't enough like lisp. I feel comfortable trashing a language design that nobody's even seen yet. Trying new things is dumb.''

''''The design principles for Arc are known. Paul Graham has talked about it and you can read about it on his web site.''''

----
I don't understand this obsession with slimness in language implementation. What's the big deal with having big libraries - it just saves you the hassle of having to reinvent EVERYTHING to do anything interesting. No one is forcing you to use all those "duplicate" CommonLisp functions. No one is forcing you to use LOOP. No one is forcing you to use CLOS.  

Just fire up your CL and go:

 CL-USER 3 > (make-package "ELITE-COMMON-LISP")
 #<The ELITE-COMMON-LISP package, 0/16 internal, 0/16 external>

 CL-USER 4 > (in-package "ELITE-COMMON-LISP")
 #<The ELITE-COMMON-LISP package, 0/16 internal, 0/16 external>

  ELITE-COMMON-LISP 5 > (shadow 'cons)
  T

  ELITE-COMMON-LISP 6 > (cons 'a '())

 Error: Undefined operator CONS in form (CONS (QUOTE A) (QUOTE NIL)).
  1 (continue) Try invoking CONS again.
  2 Return some values from the form (CONS (QUOTE A) (QUOTE NIL)).
  3 Try invoking something other than CONS with the same arguments.
  4 Set the symbol-function of CONS to another function.
  5 Set the macro-function of CONS to another function.
  6 (abort) Return to level 0.
  7 Return to top loop level 0.

 Type :b for backtrace, :c <option number> to proceed,  or :? for other options
Ahhhhhhhh. That's much better. Now I can code without that d*mmed CONS operator gettin' in my way!
----
''I don't understand this obsession with slimness in language implementation. What's the big deal with having big libraries - it just saves you the hassle of having to reinvent EVERYTHING to do anything interesting. No one is forcing you to use all those "duplicate" CommonLisp functions. No one is forcing you to use LOOP. No one is forcing you to use CLOS.''

Wow. Wow.

I mean, ''Wow.''

I reread that paragraph no less than 6 times, and I ''still'' can't parse it. 

Re: "I don't understand this obsession with slimness in language implementation."

Are you saying that you do not care about a language with a slim syntax, like C, versus a language with a complex syntax, like PL/I?

''{He's saying he thinks it is great that lisp has large libraries that interact with the lisp language syntax and make it a large language. Lisp is a bit odd in that it's syntax is redefine-able, allowing for lisp to become large, whereas in C (without a preprocessor) the language can't grow big.. it's fixed as Cee. Redefining Lisp allows it to grow into a massive mess - there is less discipline to keep it tiny. Yet lisp base syntax that you are given to start with (brackets) is very simple and small - not large at all. Lisp's base syntax is even more slim than C.. It's just a bunch of brackets. Some even joke that '''lisp has no syntax'''.  I think "simpler, but no simpler" applies here..  Lisp is so simple ('''too''' simple) that it allows you to build up from '''bottom up''' and redefine everything at run time, leading to everyone inventing their own programming languages within lisp. This makes it hard for people to understand other people's lisp code since it's all redefined and customized, whereas more general languages like CeeLanguage aren't redefined everywhere across code bases (unless you redefine Cee with the macro preprocessor, shunned by many). In Cee it is shunned to redefine the language, whereas in Lisp it is encouraged. It's almost as if Lisp programers completely ignore the fact that redefining code makes it harder to read, and they pretend there are no disadvantages of this practice, whereas Cee programmers hate it when someone redefines Cee with clever macro preprocessor tricks all over the code - they consider redefining the language a disadvantage of the preprocessor. Lisp is a bag of tricks, which is a DoubleEdgedSword.}''

Re: "What's the big deal with having big libraries - it just saves you the hassle of having to reinvent EVERYTHING to do anything interesting."

I'm assuming that by this you mean you ''do not'' have a big deal with big libraries. But the first half of the sentence (I'm assuming it's supposed to be a question) suggests that you might have some issues with them.

I think the paragraph needs to be refactored. Badly. :) As for the ''rest'' of your comment, I largely concur.

I suppose the reason for any kind of MCL at all would boil down to smaller environments - no one would ever code in ANSI Common Lisp for a PIC microcontroller, for example. Not if you want the code to run ''on'' the PIC at least (versus running a virtual machine on the PIC, and the CL program is written to the VM). And, yet, I can see how it is strongly desirable to use a Lisp-family language for embedded programming work.

-- SamuelFalvo

----
CategoryLisp