The lack of an MVC distinction, the lack of multithreading, the age of the Lisp dialect... the reasons to rewrite Emacs keep on growing, but the problem of maintaining compatibility with existing Lisp is a high bar. I wonder if the best approach is to rewrite the core from scratch, using a better Lisp (Scheme or CL, your pick), and then write an elisp bytecode interpreter in that better Lisp. (For full marks, write an elisp interpreter as well: if you've got the bytecode semantics right the textual interpreter should be quite easy).
The hard part is preventing changes in semantics from things like multithreading from breaking old-elisp packages... but this is a subject of perennial discussion on emacs lists everywhere, which never quite seems to get off the ground.
Posted Apr 6, 2010 10:55 UTC (Tue) by wingo (subscriber, #26929)
[Link]
Actually, Guile is working on just this: compiling Elisp to Guile's VM, maintaining back compatibility while also allowing Scheme, providing new features, and new languages too. I think we have a good multithreading story as well.
Posted Apr 7, 2010 17:10 UTC (Wed) by nix (subscriber, #2304)
[Link]
I note the foreign-language recursive acronym sequence fairies have been at the editor substrate climacs uses. Remember the old editors Eine (Eine Is Not Emacs) and Zwei (Zwei Was Eine Initially)? Well, climacs is built on Drei (Drei Replaces Eine's Inheritor)...