Re: Emacs Lisp and Guile

[Neil Jerram <neil@ossau.uklinux.net>]

[-- Attachment #1: Type: text/plain, Size: 2726 bytes --]

>>>>> "Richard" == Richard Stallman <rms@gnu.org> writes:

         I think that both these restrictions point in the same direction: the
         way forward is to define the primitives by compiling a preprocessed
         version of the Emacs source code, not by trying to implement them in
         Scheme.

    Richard> What precisely is "a preprocessed version"?  What I think
    Richard> we should do is modify the code in Emacs so that it works
    Richard> with Scheme.

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?)

         Unless this picture changes, I don't plan to do any further
         significant work on the prototype translator.

    Richard> Putting aside the issue of the Emacs primitives, which we
    Richard> are going to handle with C code and should not be
    Richard> implemented in Scheme, does it need any more work?  Not
    Richard> counting those primitives, are there Emacs Lisp features
    Richard> it does not handle?  Or is it adequate as it stands?  (If
    Richard> so, why call it a "prototype"?  Why not call it
    Richard> "finished"?)

1. The Guile reader doesn't directly handle all Elisp syntax -- e.g. [
] for vectors and ? for character/integers.  The translator retrofixes
some of these discrepancies -- e.g. it turns (what it sees as) symbols
for the obvious alphabet characters (?a, ?b etc.) into Guile integers
-- but not all of them.

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

3. There's no byte code interpreter.

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.

It's adequate as it stands for the programmer who wants to write
general purpose code using (mostly) Emacs Lisp syntax and language
constructs.  (For an example, see the attached file, which is included
in Guile CVS for this purpose.)  It's not adequate for the programmer
who wants easily to build an editor application by taking advantage of
a large set of relevant primitives and data types.

If we assume that primitives, data types, special forms, the reader
and the byte code interpreter are all dealt with by using the Emacs C
code, I think the only design issue remaining is the representation of
Elisp variables so that buffer- and frame-local values are supported.

Does this sufficiently answer your questions?  Please let me know if
not.

        Neil


[-- Attachment #2: Example of Elisp code that translator can handle --]
[-- Type: application/emacs-lisp, Size: 1224 bytes --]