Logistics of Using Guile

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

RE: Logistics of Using Guile

[Drew Adams]

> I realize not everyone agreed that using Guile was good,
> for several reasons, but I believe most people did.

FWIW - You may believe it ;-), but I would not assume that.

Re: Logistics of Using Guile

[Noah Lavine]

I would say that if Emacs uses Guile then we will have other people
worrying about interpreter speed so we don't have to (there's talk on
the Guile website of a JIT compiler), and it will be much easier to
extend Elisp if we want to do that (in order to implement a language
in Guile 2.0, all you need to do is compile it to any other language
that Guile supports, including the convenient intermediate languages
they provide).

In other words, it's a one-time effort for a long-term payoff. If the
effort is not horrible, it seems to make sense to do it.

Noah Lavine

On Thu, Apr 22, 2010 at 9:27 PM, David Reitter <david.reitter@gmail.com> wrote:
> On Apr 22, 2010, at 6:51 PM, Drew Adams wrote:
>
>>> I realize not everyone agreed that using Guile was good,
>>> for several reasons, but I believe most people did.
>>
>> FWIW - You may believe it ;-), but I would not assume that.
>
> Does it matter? Guile is another GNU project, so Emacs should use it!
>

Re: Logistics of Using Guile

[Andy Wingo]

Hi Noah,

On Fri 23 Apr 2010 00:21, Noah Lavine <noah549@gmail.com> writes:

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

For me, #2 is the only realistic option.

There are a couple of outstanding projects you might not be aware of:

 1. Ken Raeburn's Guilemacs -- http://www.mit.edu/~raeburn/guilemacs/

    Ken is currently working on rebasing his patches in this branch
    against current bzr.

 2. Brian Templeton's summer-of-code project (pending)

    http://thread.gmane.org/gmane.lisp.guile.devel/10163

    Brian is going to polish off Guile's Elisp compiler, and attempt to
    flesh out what the problems are going to be when replacing Emacs'
    elisp implementation.

    The biggest problem is, as I mention in my reply in Brian's thread,
    that there are many unknowns about such a rebase.

Also I think that the Elisp implementation is in an OK state, but
probably still needs a couple months' work.

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

Cool! Perhaps the best of all possible worlds™ would be for Ken to push
his branch within the next 2-3 weeks, and you could investigate from
there. AFAIUI, Ken's branch makes Emacs use Guile data structures, but
keeps Emacs' Elisp implementation. Then swapping out the elisp
implementation would be a more manageable change.

Regards,

Andy
-- 
http://wingolog.org/