Re: Emacs Lisp and Guile

[Richard Stallman]

    What you suggest would be ideal.  I only talked about a "preprocessed
    version" because I was assuming that it might not be feasible to start
    modifying the primary Emacs codebase immediately.  If this assumption
    is wrong, so much the better.  (Would you agree with this, Ken?)

We may be miscommunicating.  I was talking about the right way to do
this eventually.  We certainly are not at the point of doing it now.

    1. The Guile reader doesn't directly handle all Elisp syntax -- e.g. [
    ] for vectors and ? for character/integers.

Since Emacs Lisp syntax is not the same as Guile syntax, we will need
a reader that handles Emacs Lisp syntax--unless it happens that the
Guile reader could be customized to support Emacs Lisp syntax.  Is
that feasible?

    2. The representation of Elisp variables doesn't allow for buffer- and
    frame-local variables.

How to handle these in a Guile-based system is not obvious, but they are
such important features that we must make them work.

    3. There's no byte code interpreter.

I don't think we need to support the Emacs Lisp byte code interpreter
if we have some equally efficient or more efficient way to run an
Emacs Lisp program.  Source compatibility is the important kind of
compatibility here.

    4. There are special forms that I haven't implemented
    (e.g. condition-case) and several data types (e.g. buffers, char
    tables); but these are all really in the same category as primitives,
    so no big deal.

condition-case needs to be handled; that is a language construct,
not an editing primitive.

The functions that operate on buffers would be implemented by C code,
the same as now, so they are not part of the scope of implementing the
Emacs Lisp language.  However, the issue of the data representation to
use for them is a significant one.