could one compile elisp to common lisp?

I have seen a push toward native compilation with gccemacs. If i remember correctly, some common lisp implementations already compile lisp to machine code (like sbcl). Since elisp and common lisp are both in the same family, i was wondering how difficult would it be to compile the elisp libraries in emacs into common lisp, load them into an sbcl image, and obtain emacs with native compilation built in. This could be further interfaced with other common lisp projects like Nyxt to provide further functionality. Would something like this be feasible?

Yes, I think you could theoretically recompile elisp to just about anything (practicalities and performance notwithstanding). Tom Tromey did some prototype work on the Common Lisp idea years ago: https://tromey.com/blog/?p=778 At this point in time (with the gccemacs solution having undergone not merely prototyping, but the very substantial development effort necessary to actually be merged and included in a stable release of GNU Emacs) I imagine that there's no practical likelihood of any other alternatives being considered anytime soon.

The larger issue is that the Emacs internal data structures -- things like buffers, windows, frames, and processes -- don't have direct counterparts in CL. So you have to port that whole model over before there's much hope of everyday code being able to work. The same problem exists with any runtime other than Emacs' Lisp interpreter.

As another comment mentioned, the native comp in emacs 28 has been a good step forward. But along with emacs base providing facilities for high performance, it's also the surrounding libraries (company, swiper, more I don't use or are already ) that need to be focused on performance. The other libraries implementing inefficient algorithms won't do any good regardless of the performance of the underlying emacs. But yes, there are a couple of areas where I wish emacs (native packages) could still improve, handling of larger files with font lock mode being one of them.

How messy would you say the emacs code base is?

And where will all the C primitives specific for Emacs come from? :-) Sure you can re-implement Emacs in common lisp just as it is possible in any other language, but you still have to implement all the C primitives in that language too. If I recall Andrea Corallo from some talk, there are about 1200 (or was it 1700?) C primitives in Emacs, if I haven't forgot and confused his talk with something else. By using Common Lisp, a lot of Elisp, both that mplemented in C and that implemented in pure Lisp comes "for free", since lot of functions have same names and behave similarly, but there are also a lot of differences, same substantial and some subtle. And you still need to implement Emacs specific funcionality not found in CL implementations . Emacs is a staticly compiled application, not loose pieces of libraries, so you can just load Emacs code into a random application, or add Emacs sources to your app, but have to re-implement Emacs parts. With other words, to recompile elisp to CL is not a trivial task since it would require re-implementing a lot of Emacs in the target language.

[deleted]

> the awesome work that Lars did on speeding up the Emacs Lisp interpreter Was that not Mattias Engdegård? Unless they were both working on performance improvements?

> gccemacs is largely a failure. Other than useless microbenchmarks, the performance improvement in day to day work compared to current Emacs develop is negligible if not entirely imperceptible It's clear to me that the benefits (or lack thereof) vary hugely between users. Like you, I see no benefits so I don't use it (so like you I'm happy whenever I see performance improvements to the interpreter -- although potentially I won't notice those either). However it's extremely clear from past comments from other users that some people see *significant* benefits from gccemacs. So I think it's not "largely a failure"; it's just very much "YMMV". > Moreover, I get the feeling that whatever got merged into Emacs 28 is the end of the line, further improvements seem extremely unlikely I have no idea; but if you're basing that on Andrea not *immediately* dedicating himself to new improvements after slogging it out for more than a year to get his initial work (which was probably already years in the making) to a releasable state, I'd just say "have a heart".