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.
There is a long standing advice, not to use the CL extension of Emacs Lisp.
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.
There was also a long discussion about using Common Lisp - it never happened.
What now happens is that Emacs Lisp gets changed a bit - for example by providing real lexical binding.
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.
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.
Still, multi-tasking in GNU Emacs would be useful...
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?
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?
Yes, most of it is done in higher level elisp modules.
I think you are right, however, in that it is not obvious that it would be faster in all situations. You would get the advantage of compiling the elisp modules to machine code, but you might loose some performance in the actual operations. However, there is no fundamental reason that the C sections couldn't be left in C and called (if the performance difference is really big).
There is no reason (that I can think of) you couldn't write a cross compiler from emacs lisp to CL. They are actually fairly similar (except for maybe some scoping rules).
I'm kind of torn on this because, honestly, it has already been done a couple of times... lisp machines, and mcclim emacs, are the ones that I can think of off the top of my head. Anyway.
On a 64 bit machine it should be very good, on a 32 bit machine possibly less so.
I'm perfectly aware of that. But a lot of that code ends up shuffling and moving stuff around in buffers and that ends up as work in the C modules. I don't think the distribution of work is as obvious as you make it sound but I'm prone to believe it. As I said: I'm unsure, if my assumptions are true.
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.
It's not portable. A compiler would have to be written, and it would not produce human-editable output. Emacs Lisp will be around forever, but that doesn't mean that it needs to run slowly or be the only language with which to extend Emacs. (This is a Python 2 / Python 3 type of situation. Some programs can be automatically translated, but nobody really wants to maintain the result. A proper Python 3 port is the correct solution, using the automatic translation as the basis.)
There is a long standing advice, not to use the CL extension of Emacs Lisp.
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.
There was also a long discussion about using Common Lisp - it never happened.
What now happens is that Emacs Lisp gets changed a bit - for example by providing real lexical binding.
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.
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.
Still, multi-tasking in GNU Emacs would be useful...