Emacs and Common Lisp
tromey.comI guess I should really participate in emacs-devel a bit more, but I've always been in favor of allowing Emacs to support multiple languages with a common runtime. Emacs Lisp is slow, that's true, but there's no problem intrinsic to its syntax that makes it slow. Similarly, there's nothing intrinsically slow about the runtime that Emacs provides; it's a bog standard dynamically-typed language with the slow stuff implemented in C. What we need is a proper compiler, one that can compile Emacs Lisp to either native code, or a proper intermediate representation that can be optimized. Unladen Swallow seems like a good model.
With a proper intermediate representation, we can begin writing compilers for other languages. Then you can write your extensions in Common Lisp, or Emacs Lisp, or Scheme, or JavaScript, or Perl, or whatever you feel like writing a compiler for. This won't fragment the community, because the runtime will be the same for every language; yes, there will be syntax differences, but in the end, everyone is programming to the same API. This is different than what Vim does with its programming language support (recompile Vim to embed opaque interpreter object, pray when you choose more than one language).
The only problem is that Emacs Lisp is fine for 99.9% of use cases, and it's fast enough for 99.9% of use cases. One worry I have about "proper language support" is that people will start "engineering" Emacs extensions. (By which I mean, treating software designed for interactive use by programmers as though it's "enterprise" software. When you need to write software that must not fail, concepts like encapsulation are very important. But when you're writing software that's designed to be edited by the user while it's running, you can't write it that way. Emacs Lisp explicitly encourages this, but CL, Scheme, and JavaScript don't.)
> What we need is a proper compiler, one that can compile Emacs Lisp to either native code
This has actually been done (possibly badly?) and turned out to be a wash in terms of performance.
Yeah. It might be worth trying again, considering the good performance of newer language runtimes like SBCL, Node.js, and Unladen Swallow.
What "unladen swallow"? That project did not have the expected improvements and was abandoned...
Unladen Swallow might not be usable in production, but as a research project it's pretty interesting. One of its problems was supporting C-based extensions, but that's not a requirement for Emacs Lisp, and so a similar project might be more effective for Emacs than for Python. (I also like the idea of using LLVM for dynamic language runtimes, but as time goes forward this seems less likely to work out.)
I think one of the strength of Emacs, that has allowed it to grow that much compared to Vim, is that it has always had one official extension language. It doesn't have any external dependencies. If Emacs developers endorsed extending Emacs with other languages, users would have started using other languages libraries, which could have caused issues in portability and set up.
GNU already chose Scheme as the language of choice for Guile, which is (intended to be) to GNU as a whole what elisp is for Emacs. So I could see emacs eventually being ported to Scheme. But not CLisp.
If I recall that's already in the works
By using the "CLisp" when you mean "Common Lisp", you make yourself seem not knowledgeable enough to be speaking about the matter at hand.
He did not discuss the language itself, but GNU's choices. So the "matter at hand" seems irrelevant to the correct naming of CL.
Clisp is GNU's Common Lisp implementation.
No, he means CLisp, mr "informed"...
While this sounds like an interesting and ambitious project, I don't think it will ever get off the ground. I use Emacs daily for 80% of my work and its performance is not an issue. The author seems a bit too optimistic that a GCC plugin can automate the majority of the port to CL -- it may provide a nice start but finishing the port will me a considerable amount of tedious work and from the perspective of an Emacs user, I suspect either they won't notice the change or the change will introduce new bugs.
I use Emacs daily for 80% of my work and its performance is not an issue.
Speak for yourself. I also use Emacs daily for 80% of my work and while performance is OK, I would definitely welcome any improvements. Areas where I notice subpar performance are especially:
* paging through or searching in very large buffers (such as large log files), particularly with syntax highlighting enabled
* re-indenting large regions
Also, modes like eterm always feel a bit laggy.
And all the tiny little delays add up. It does matter to me whether skipping to the end of a large file takes 200 ms or 20 ms -- only a little bit but again, it adds up.
I wonder to what extent such a rewrite could be done incrementally. For example, can the redisplay code (which is a big, complicated mess, as one commenter in the article points out) be left in C for a start and "only" the elisp-facing code be ported? If so, this sounds like a viable approach.
I also wonder whether this would help solve the problem of lack of multi-threading in current Emacs.
> I also wonder whether this would help solve the problem of lack of multi-threading in current Emacs.
Or perhaps it's the other way around: adding multithreading to Emacs Lisp would make performance no longer a problem.
Good point. Adding multi-threading while keeping the existing elisp compiler would definitely improve responsiveness, maybe enough so to turn the issues I mentioned into non-issues. That said, the proposed approach has the potential to kill two birds with one stone: add multi-threading AND improve raw performance.
The problem with multi-threading in emacs isn't a lack of libraries to support threads, as CL would supply, but rather the complexities of synchronization of a large existing codebase, which porting to CL would have no effect.
The lack of proper multithreading has bit me many times when I try to use Emacs as an email client--start talking to the IMAP server, and your whole Emacs process takes a break. Can't edit anything, we're stuck until it either finishes or you hit C-g.
I use IMAP over SSL with Gnus, and the actual talking-to-the-network is asynchronous (handled by another UNIX process). The slow part is generating the summary buffer on large groups.
(BTW, if you use IMAP with Gnus, I highly recommend using a local IMAP server instead. You can sync to your remote IMAP server with offlineimap. This speeds up Gnus enormously for me; reading my Maildir directly from Gnus is too slow to be usable, but reading it through a local IMAP server makes reading my inbox instantaneous.)
I run a dedicate instance for Gnus for exactly that reason. Has the added benefit of keeping me from being distracted by a simple (Emacs) window change when I'm focused in my other instances.
Not to discourage, but this will never happen, at least with mainline emacs. Of course, there's nothing stopping a fork from rewriting the lower level code as suggested, but don't ever expect it to get merged. Think a different language interpreter/operating system with a common library and applications, which is exactly what this would be.
Not strictly related, but I've been thinking over a clojure+SWT emacsalike editor for a while now. It just might work.
It's a Heruclean effort but would be great. Imagine the possibilities of having all of Java available in your editor!
I'd much prefer to have all of elisp in my editor than all of Java. The existing elisp libraries are much better suited for an editing environment than Java.
Just curious: why SWT over Swing? (I've read that Java 6 included some Swing performance improvements.)
Just personal preference, really.
This has been proposed in the past.
One of the difficulties to be overcome is the huge base of existing elisp code. This code base is part of the attraction of emacs.
[Indeed](http://www.emacswiki.org/emacs/EmacsImplementations). And [this](http://en.wikipedia.org/wiki/Emacs#Other_forks_and_clones).
That said, I wonder about the possibility of taking an Emacs written in some other language and adding an Elisp interpreter to it such that it could make use of all the existing Emacs elisp out there.
In the comments, what important truths about GNU's nature is Tom talking about? (Where he writes "but recently I have learned, painfully, that I was only part of GNU by denying important truths about its nature.")
I'd rather have a Emacs on JavaScript; with a possibility to be run from the browser. (Yes I know, that'd mean rewriting everything. Not the end of the world, it'll be fun time.)
Not necessarily... The vast majority of emacs is written in elisp, and the amount of instructions written in C is actually rather small, It's been a while, but on the order of a few hundred too a few thousand.
Once you were to rewrite the elisp interpreter, and other calls from C into JavaScript, in theory, running emacs in you're browser isn't actually that absurd.