Guile Scheme and Emacs Lisp

["Kei Nishida" <kei@psn.net>]

Hi,

I was sending email to Ken Raeburn about Guile Emacs, and this is
a copy.  What do you think about this, everyone?

-----------------------------------------------------------------------
Hi Ken,

I read the Jim Blandy's notes about Lisp's nil vs. Scheme's ()/#f, and
realized some problems of translating elisp into scheme.  I thought
about this for a while, and this is my conclusion.

It is impossible to make the existing elisp programs interact well with
the new scheme programs, even though it is possible to make the elisp
programs work correctly on the new system.  In other words, the existing
programs are able to work on Guile Emacs, but if people who want to use
elisp on the new system are going to utilize its new features or to
communicate with other programs written in another language, they MUST
use a new elisp interface, right?

Since Guile permits several languages on the same system, there should
be a certain consensus of their interfaces, such as possible objects
(including nil/#f), treatments of variables and functions, ways of
communication each other.  I think it should be basically based on the
scheme's interface, so current elisp cannot get along with it.

What we have to do is to make use of the existing properties in elisp on
the new system, not to write new programs in current elisp exactly.
This means we'd better think about two methods of translating elisp into
scheme: utilizing the existing programs on the new system, and providing
new features for elisp users.

The purpose of the former is to run the existing elisp software somehow
or other; all programs will be evaluated in the same, huge, and closed
(in principle) environment.  Every code cannot access to another
environment nor new features without translater's help.  Although
another languages can access to elisp programs, they should beware
because the programs are not under the consensus.

The purpose of the latter is to allow users to have good ability to
communicate with other programs in anohter language.  This new Emacs
Lisp, let's call Guile Emacs Lisp, will be similar to current Emacs Lisp
but more like Scheme, including the features of distinction between nil
and #f, and holding functions as variables.  These features should be
the same with other languages in order to share information each other.

                           Guile Emacs
        .--------------------------------------------------,
        |                                                  |
        |                       Guile Language Agreement   |
        |  .------------,  ok  .------------------------,  |
        |  | good old   | <--- | Scheme, CTAX, Perl,    |  |
        |  | Emacs Lisp | ---> | Guile Emacs Lisp, ...  |  |
        |  `------------'  no  `----------||------------'  |
        |        |             .----------||------------,  |
        |        +-----------> |   Emacs primitives     |  |
        |   elisp translater   `------------------------'  |
        |                                                  |
        `--------------------------------------------------'

Emacs primitives should be designed for Scheme or Guile Emacs Lisp.
Taking care of the difference between Scheme's #f and Lisp's nil is a
job of the elisp translater.  Every code in old elisp should work well
as long as runing in the elisp environment thanks to the translater.
The old code never refers to any other environments because it doesn't
know anything about Guile.

The user can extend Emacs using Guile Emacs Lisp or any other language
with all advantage of Guile and Emacs primitives.  The user don't need
to take care of the old elisp programs, except when he/she wants to get
along with them; in that case, how to communicate with the old programs
is her/his responsibility.  Some users might transrate the programs into
Guile Emacs Lisp or others.  It should not be hard work.

The only matter I can see is about global/customizable variables.  If an
elisp program set a global variable to nil, how can another language
treat it?  Well, maybe some tricks will be needed.  The global varible
needs to have a type and a change-driven hook.  If the variable is
changed in the elisp environment, it must actually be set as () or #f in
the global environment, and vice versa.  This feature will also be
useful in general.

More complex variables, like hooks, might not be able to be treated
automatically.  Any programs using such variables will possibly need to
be rewritten somewhat... yes, I believe it is the Right Thing.

This is the general idea I have thought about Guile Scheme and Emacs
Lisp.  What do you think about this?
-----------------------------------------------------------------------

I now suppose it is not necessary to design a new elisp language if
some extentions are added to current elisp, but still I think we have
to think about the interface between languages.  This is another figure
of the general structure:

             .---------------------------------,
       User  |  Emacs General User Interface   |           Keyboard
             `------V-----------------V--------'           Mouse
  - - - - - - - - - V - - - - - - - - V - - - - -
             .------------,  .-----------------,  .-----,
  Developer  | Emacs Lisp |<-| Guile Languages ====  G  |  Extention
             `-----|------'  `-------||--------'  |  U  |  Languages
  - - - - - - - - -|- - - - - - - - -|| - - - - - |  I  |
             .-----|------,  .-------||--------,  |  L  |
     System  |Elisp Engine|->| Emacs Primitives====  E  |  Scheme, C
             `------------'  `-----------------'  `-----'
             ==============  ===================
               Emacs Lisp      Guile Lauguage
               Environment   Interface Agreement

I am trying writing a translater from elisp into scheme for thinking.
I've heard somebody has done something of this.  Could I have it in
some way?  I failed to get the "mdj_elisp_branch" mentioned in the
Guile Emacs' web page. (http://www.mit.edu/~raeburn/guilemacs/)

And how are the stuations of other translaters?  Is there any
consensus between them?  How well are they going?

I'm also interested in the proposal for Guile's new top-level
environment. (http://www.gnu.org/software/guile/docs/env.html)
Is it available or is anyone working on it yet?

-- Kei