
Emacs and Common Lisp - fogus
http://tromey.com/blog/?p=709
======
lispm
Richard Stallman didn't want to use Common Lisp when he wrote GNU Emacs. The
work on the Common Lisp definition started in 1982 and CLtL1 was released in
1984. Stallman started his work in 1984. Richard also knew the Emacs variant
on the Lisp Machine. He did not want lexical binding (Common Lisp), he did not
want object-oriented programming (Flavors on the Lisp Machine, later CLOS in
Common Lisp) and he wanted a simple Lisp dialect based on Maclisp. He did not
want to have a more modern Lisp dialect based on Maclisp, like Lisp Machine
Lisp or Common Lisp.

There is a long standing advice, not to use the CL extension of Emacs Lisp.

The GNU project at one point wanted to settle on Guile/Scheme as its extension
language - there was some talk to use it in Emacs - but it never really
happened.

There was also a long discussion about using Common Lisp - it never happened.

What now happens is that Emacs Lisp gets changed a bit - for example by
providing real lexical binding.

If the GNU Emacs project would use Common Lisp, the nature of the extension
language changes. Less painful would be to use a Common Lisp variant with the
feature set of CLtL1 + threads. ANSI CL with CLOS is a different thing.

Of all the many variants of Emacs (for example Hemlock in Common Lisp, CLimacs
in Common Lisp, ...) none has the feature set and the multitude of extensions
like GNU Emacs.

Still, multi-tasking in GNU Emacs would be useful...

------
julian37
Previous discussion: <http://news.ycombinator.com/item?id=3433424>

~~~
akkartik
Also relevant is this argument that a language with dynamic binding is well-
suited to editor extensions.

<http://news.ycombinator.com/item?id=3279258>

------
p4bl0
The most interesting part is the discussion about Guile vs CL for GNU Emacs in
the comments.

------
pmr_
I don't understand the performance argument. The core editing facilities of
Emacs are written in C and I doubt how CL or Guile could outperform this.
Maybe my perception of the work-distribution in Emacs is skewed: Is most of
the work done in the core editing facilities or in the higher level elisp
modules?

Some questions that remain: Is old elisp code going to benefit from a rebased
Emacs: Is it going to be faster or maybe even slower? How should the longterm
plan look? Is everybody supposed to port existing code to CL at some point or
is old code going to be supported indefinitely?

~~~
lispm
Editing is a part of GNU Emacs. But it is also a Mail, News, whatever client.
It comes with a million lines of Lisp code.

~~~
pmr_
I'm perfectly aware of that. But a lot of that code ends up shuffling and
moving stuff around in buffers and that ends up as work in the C modules. I
don't think the distribution of work is as obvious as you make it sound but
I'm prone to believe it. As I said: I'm unsure, if my assumptions are true.

------
yason
I would like to hear about the actual problems in the Elisp runtime. Does
anyone remember a reference to an article that details the implementation of
Elisp in more depth?

------
babarock
I don't know LISP well enough to ponder how portable all the existing elisp
code base would be portable to CL. Imho this could be the deciding factor
between a permanent shift for emacs or a mere fork.

~~~
jrockway
It's not portable. A compiler would have to be written, and it would not
produce human-editable output. Emacs Lisp will be around forever, but that
doesn't mean that it needs to run slowly or be the _only_ language with which
to extend Emacs. (This is a Python 2 / Python 3 type of situation. Some
programs can be automatically translated, but nobody really wants to maintain
the result. A proper Python 3 port is the correct solution, using the
automatic translation as the basis.)

