Emacs and Common Lisp

Richard Stallman didn't want to use Common Lisp when he wrote GNU Emacs. The work on the Common Lisp definition started in 1982 and CLtL1 was released in 1984. Stallman started his work in 1984. Richard also knew the Emacs variant on the Lisp Machine. He did not want lexical binding (Common Lisp), he did not want object-oriented programming (Flavors on the Lisp Machine, later CLOS in Common Lisp) and he wanted a simple Lisp dialect based on Maclisp. He did not want to have a more modern Lisp dialect based on Maclisp, like Lisp Machine Lisp or Common Lisp.<p>There is a long standing advice, not to use the CL extension of Emacs Lisp.<p>The GNU project at one point wanted to settle on Guile/Scheme as its extension language - there was some talk to use it in Emacs - but it never really happened.<p>There was also a long discussion about using Common Lisp - it never happened.<p>What now happens is that Emacs Lisp gets changed a bit - for example by providing real lexical binding.<p>If the GNU Emacs project would use Common Lisp, the nature of the extension language changes. Less painful would be to use a Common Lisp variant with the feature set of CLtL1 + threads. ANSI CL with CLOS is a different thing.<p>Of all the many variants of Emacs (for example Hemlock in Common Lisp, CLimacs in Common Lisp, ...) none has the feature set and the multitude of extensions like GNU Emacs.<p>Still, multi-tasking in GNU Emacs would be useful...

Previous discussion: <a href="http://news.ycombinator.com/item?id=3433424" rel="nofollow">http://news.ycombinator.com/item?id=3433424</a>

The most interesting part is the discussion about Guile vs CL for GNU Emacs in the comments.

I don't understand the performance argument. The core editing facilities of Emacs are written in C and I doubt how CL or Guile could outperform this. Maybe my perception of the work-distribution in Emacs is skewed: Is most of the work done in the core editing facilities or in the higher level elisp modules?<p>Some questions that remain: Is old elisp code going to benefit from a rebased Emacs: Is it going to be faster or maybe even slower? How should the longterm plan look? Is everybody supposed to port existing code to CL at some point or is old code going to be supported indefinitely?

I would like to hear about the actual problems in the Elisp runtime. Does anyone remember a reference to an article that details the implementation of Elisp in more depth?

I don't know LISP well enough to ponder how portable all the existing elisp code base would be portable to CL. Imho this could be the deciding factor between a permanent shift for emacs or a mere fork.