Logistics of Using Guile

[Noah Lavine]

Dear Emacs developers,

I'd like to follow up the recent discussion of using Guile as Emacs'
language engine with a question about some practical issues of making
the switch. I realize not everyone agreed that using Guile was good,
for several reasons, but I believe most people did. I would also point
out to people who don't like it that using Guile doesn't require using
features of Guile we don't like, like non-Elisp languages: we could
use Guile as a faster Elisp interpreter and change nothing else, it
would be nice to have a faster Elisp interpreter.

The situation as I see it is this: Guile already has an implementation
of Elisp that is at least mostly done, if not entirely done, but it
only includes the standard Lisp objects - numbers, strings, lists,
vectors, etc. The next step, before we could use Guile to run Emacs,
is porting all of the C code that deals with files, buffers, display,
etc. As far as I can tell there are three options for doing this:

1. Write a C translation layer to convert between SCM (Guile
representation) and Lisp_Object (Elisp representation) of values at
runtime.

2. Rewrite src/lisp.h, the file with all the macros dealing with
Lisp_Objects, to use Guile SCM stuff, and then recompile all of the
Emacs sources that we want.

3. Port the Emacs C code manually to use SCM.

The relevant Guile API is at
http://www.gnu.org/software/guile/docs/master/guile.html/API-Reference.html,
and the Elisp API is documented somewhat at
http://www.gnu.org/software/emacs/manual/html_node/elisp/Writing-Emacs-Primitives.html,
but mostly just in the source code as far as I can tell.

I'm not entirely sure which one would be better now. One concern with
trying to interoperate is that the Elisp stuff is implemented as C
macros, so if there are name conflicts, I don't know of any options to
deal with them. That would suggest option #3. Also, any option other
than 3 has the potential to involved bitfield munging or something
else unpleasant like that, which seems better to avoid if possible.

However, obviously number 3 would require work proportional to the
number of lines of C to be converted, whereas the other options
require work proportional to the size of the APIs to be converted, so
depending on the sizes of those things the first two options could be
better.

Does anyone know of any reason to choose one of the three options?

(I'm asking this partly in the hope that I would have enough
information to plausibly start hacking in about three weeks, when I
anticipate having some free time to do things like this.)

Noah Lavine