from Hacker News

Emacs and Common Lisp

by michaelty on 1/6/12, 2:42 PM with 31 comments

• by jrockway on 1/6/12, 5:29 PM

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

• by drcube on 1/6/12, 3:47 PM

  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.

• by smountcastle on 1/6/12, 3:22 PM

  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.

• by kruhft on 1/6/12, 4:31 PM

  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.

• by regularfry on 1/6/12, 4:22 PM

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

• by wglb on 1/6/12, 6:27 PM

  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.

• by wicket232 on 1/6/12, 7:52 PM

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

• by phzbOx on 1/6/12, 6:01 PM

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