Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much)

[Ken Raeburn <raeburn@raeburn.org>]

> Is there a way to use Guile (Scheme?) to emulate Emacs Lisp?  I think
> somebody has written a Common Lisp module that emulates Emacs Lisp,
> but I haven't heard about Guile/Scheme.

I think as a proof of concept you could write a machine-code and
system-call emulator in Scheme, and run the current Emacs binary
including its Lisp interpreter, so, yes.  Of course, the interesting
trick is to do it more efficiently than that. :-)

People have definitely worked on it.

The Guile CVS repository contains some code that loads quite a bit of
elisp.  I haven't looked at it in a while, so I can't tell you
anything about the performance, but I think it did depend on some
extension code written in C; why, I'm not sure, but that costs some
karma points in my book.

Some XEmacs people (including one who told me he's interested in
converting XEmacs to a Scheme base, but not with Guile) are developing
techniques for doing static analysis of Lisp code to determine when
dynamic bindings can be replaced with static bindings, to enable the
generated Scheme code to be more efficient.  Their goal is (possibly
expensive) conversion of Lisp libraries into Scheme libraries, which
could then be loaded at run-time as Scheme, or compiled, whatever.

> Or is the idea to have two languages side-by-side in Emacs?  I think
> this side-by-side feature is a strong point of Guile.  But I don't
> know much about Guile, so this could be totally wrong.

If we don't have full run-time translation, we can still use the
existing interpreter, modified to work with the new shared object
representation.  In fact, that's my first goal, having the modified
Lisp interpreter run Emacs, without even having any Scheme code
running at all.  Then get Scheme going, and at least minimal
interaction between the two languages.

I think it would be a mistake to stop there.  The Guile folks have a
decent run-time byte-code generator running, and machine code
generation may be a possibility down the road.  Converting Emacs Lisp
byte codes to C should be pretty easy too, but my impression is that
Scheme lends itself better to certain kinds of optimizations.  (For
example, lexical binding means you can use C local variables instead
of setting and restoring bindings of global variables, and the C
optimizer can probably do a better job with that.)

It'll certainly be worth looking at more closely.  Will it be a
worthwhile change?  That'll depend on a lot of factors.  We may find
that Guile needs a lot of work to bring its speed up to the level we
need.  We may find its memory use to be a problem.  These and other
parts of Guile are being worked on now; it's hard to predict where
they'll stand when we're ready to look at this question.