Common Lisp as Emacs language

[j***@gmail.com]

I feel like it should be possible to write a compatibility library so Common Lisp can run Emacs Lisp code. If you did that, you could swap out the current Emacs Lisp implementation in Emacs for an existing Common Lisp implementation. If you loaded *.el and .emacs files with the compatibility layer enabled automatically, you could run existing Emacs Lisp code unchanged and write future Emacs extensions in Common Lisp.

Does that sound interesting to anyone?

[Pascal J. Bourguignon]

Post by j***@gmail.com
I feel like it should be possible to write a compatibility library so
Common Lisp can run Emacs Lisp code. If you did that, you could swap
out the current Emacs Lisp implementation in Emacs for an existing
Common Lisp implementation. If you loaded *.el and .emacs files with
the compatibility layer enabled automatically, you could run existing
Emacs Lisp code unchanged and write future Emacs extensions in Common
Lisp.
Does that sound interesting to anyone?

Yes, and it is a lot of work.

It has been discussed to death (check usenet archives).

Check portable hemlock, it contains a unused/elisp/ directory with some
stuff not finished yet.

Check http://tromey.com/blog/?p=709

I'm currently working slowly on implementing a C parser in Common Lisp,
with the purpose of reading the C sources of emacs, and translating them
in Common Lisp, therefore hosting GNU emacs on a CL implementation.
Don't hold your breath, unless you're willing to finance the work.

GNU emacs represents 40 years of work, starting with a small team (I
include the TECO time), and growing with thousands of developers.
So several thousands of man.year work. To reproduce it in any
significant amount will therefore represent thousands of man.year
work. Or a cost of several $100M. If you just existed your startup and
are in or close to the three-comma club, then you could easily finance
the common-lispization of GNU emacs. It's a thing people like this kind
of do (cf. Shuttleworth with ubuntu). Strangely, I doubt that you could
sell a pitch for a startup doing that with Paul Graham though.

(Granted, if we only deal with the C code, leaving the elisp code as-is,
we reduce the problem. But only by a factor of 2. O(100M) = O(200M).)


If you want to write GNU emacs extensions in Common Lisp, there's also
emacs-cl which works in emacs 23 (before lexical bindings). You could
work on it to port it to emacs 24 (with lexical bindings). This should
simplify emacs-cl greatly, and if you can make emacs-cl more completely
conforming, it would be a nice base to write GNU emacs programs in
Common Lisp.


If you just want AN emacs written in Common Lisp, and where you can
write the extensions in Common Lisp, then you can use Portable Hemlock
(or the derived hemlock found in ccl, which is quite nice on MacOSX).

But here again, Portable Hemlock would need a lot of love to make it
usable on X (currently it's rather bad, using a separate X window for
the minibuffer and with various failures due to X11 bitrot.

[j***@gmail.com]

I wasn't thinking of translating the C part of Emacs into Common Lisp, just changing it enough to play nice with Clisp or similar and then bringing in the Common Lisp/Elisp compatibility layer. Would that be any simpler?

[Pascal J. Bourguignon]

Post by j***@gmail.com
I wasn't thinking of translating the C part of Emacs into Common Lisp,
just changing it enough to play nice with Clisp or similar and then
bringing in the Common Lisp/Elisp compatibility layer. Would that be
any simpler?

Indeed, that's another solution, to compile emacs with ecl.

It shouldn't be too hard to do.

The problem with this solution is that you get two different world, the
CL world and the emacs lisp world. And you have to provide a FFI to
make it easy to cross.

For example, the kind of problems you have then:

A cl:string is a cl:vector of cl:character (this is something that
exists), which is a cl:array of cl:character, and a cl:vector of
cl:character is also a cl:sequence (multiple-inheriting).

In emacs lisp, strings are not vectors, there are no arrays.
Happily (despite what the doc says), strings are sequences too.
Then you have strings with properties and string without properties.
And since there is no character type in emacs lisp, characters are
integers, and strings can be encoded differently whether they're unibyte
or multibyte and this is a real mess.

So basically there will be no way to use a CL function on an emacs lisp
string. The FFI will have to convert one to another, or you will have
to go thru the FFI to call the emacs lisp functions to process the emacs
lisp strings.

I'm not saying that, with a lot of macrology and automatic code
generation for the interfaces, you couldn't reach a point where you
could easily enough define a command in Common Lisp or process some CL
text with emacs lisp editing functions. But this will be a lot of work
for a Rube Goldberg machine. And you can already do that with
slime/swank! See:
https://github.com/informatimago/emacs/blob/master/slime-rpc.el

So if you want to learn something about embedding ecl in an application,
you're welcome to try to do it with emacs, and have some fun. You might
surprise us.