Emacs and Common Lisp

44 points by michaelty 14 years ago | 31 comments

jrockway 14 years ago |

I 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.)

technomancy 14 years ago | |

> 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.

jrockway 14 years ago | | |

Yeah. It might be worth trying again, considering the good performance of newer language runtimes like SBCL, Node.js, and Unladen Swallow.

lelele 14 years ago | |

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.

drcube 14 years ago |

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.

bitdiddle 14 years ago | |

If I recall that's already in the works

xyzzyz 14 years ago | |

By using the "CLisp" when you mean "Common Lisp", you make yourself seem not knowledgeable enough to be speaking about the matter at hand.

Peaker 14 years ago | | |

He did not discuss the language itself, but GNU's choices. So the "matter at hand" seems irrelevant to the correct naming of CL.

jrockway 14 years ago | | |

Clisp is GNU's Common Lisp implementation.

dextorious 14 years ago | | |

No, he means CLisp, mr "informed"...

http://www.clisp.org/

smountcastle 14 years ago |

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.

julian37 14 years ago | |

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.

technomancy 14 years ago | | |

> 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.

kruhft 14 years ago |

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.

regularfry 14 years ago |

Not strictly related, but I've been thinking over a clojure+SWT emacsalike editor for a while now. It just might work.

Bootvis 14 years ago | |

It's a Heruclean effort but would be great. Imagine the possibilities of having all of Java available in your editor!

Arelius 14 years ago | | |

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.

wicket232 14 years ago | |

Just curious: why SWT over Swing? (I've read that Java 6 included some Swing performance improvements.)

regularfry 14 years ago | | |

Just personal preference, really.

wglb 14 years ago |

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.

wicket232 14 years ago | |

[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.

wicket232 14 years ago |

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.")

phzbOx 14 years ago |

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.)

Arelius 14 years ago | |

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.