Recently I’ve been thinking about how to rebase Emacs on Common Lisp.
First, why rebase? Performance is the biggest reason. Emacs Lisp is a very basic lisp implementation. It has a primitive garbage collector and basic execution model, and due to how it is written, it is quite hard to improve this in place.
Seccond, why Common Lisp? Two reasons: first, Emacs Lisp resembles Common Lisp in many ways; elisp is like CL’s baby brother. Second, all of the hard problems in Lisp execution have already been solved excellently by existing, free-software CL implementations. In particular, the good CL implementations have much better garbage collectors, native compilation, threads, and FFI; we could expose the latter two to elisp in a straightforward way.
By “rebase” I mean something quite ambitious — rewrite the C source of Emacs into Common Lisp. I think this can largely be automated via a GCC plugin (e.g., written using David Malcolm’s Python plugin). Full automation would let the CL port be just another way to build Emacs, following the upstream development directly until all the Emacs maintainers can be convinced to drop C entirely (cough, cough).
Part of the rewrite would be dropping code that can be shared with CL. For example, we don’t need to translate the Emacs implementation of “
cons“, we can just use the CL one.
Some CL glue would be needed to make this all work properly. These days it can’t be quite as small as elisp.lisp, but it still would not need to be very big. The trickiest problem is dealing with buffer-local variables; but I think that can be done by judicious use of
define-symbol-macro in the elisp reader.
Emacs might be the only program in the world that would see a performance improvement from rewriting in CL . The reason for this is simple: Emacs’ performance is largely related to how well it executes lisp code, and how well the GC works.