

Emacs and Common Lisp - michaelty
http://tromey.com/blog/?p=709#comments

======
jrockway
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
> 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
Yeah. It might be worth trying again, considering the good performance of
newer language runtimes like SBCL, Node.js, and Unladen Swallow.

~~~
dextorious
What "unladen swallow"? That project did not have the expected improvements
and was abandoned...

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

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

~~~
xyzzyz
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
He did not discuss the language itself, but GNU's choices. So the "matter at
hand" seems irrelevant to the correct naming of CL.

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

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

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

------
kruhft
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
Not strictly related, but I've been thinking over a clojure+SWT emacsalike
editor for a while now. It just might work.

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

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

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

