Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!swrinde!pipex!sunic!trane.uninett.no!eunet.no!nuug!EU.net!uunet!news.cygnus.com!nntp!lord
From: lord@x1.cygnus.com (Tom Lord)
Subject: Emacs in Scheme!
Message-ID: <LORD.94Sep10220125@x1.cygnus.com>
Followup-To: comp.lang.scheme
Sender: news@cygnus.com
Nntp-Posting-Host: x1.cygnus.com
Organization: Cygnus Support
Date: Sun, 11 Sep 1994 05:01:25 GMT
Lines: 78




Emacs and Elisp have three very useful properties:

	1. They are well known, and well documented.
	2. Elisp's abstractions work on both on graphics and ascii terminals.
	3. There is a large library of useful elisp code.

This makes me doubt that it is a good idea to glom a Scheme compiler
onto Emacs with hopes of converting existing packages to Scheme.  I
think it would be a clever hack -- i'm just not sure it would be all
that useful.  After all, there is a lot of elisp to convert if you
want to convert elisp to scheme; it will be tedious to make the new
Scheme-based abstractions work as well as elisp on both graphics and
ascii terminals; and it would be a lot of work to educate the world
about the new system, not to mention a waste of a lot of established
state.

I like Scheme too, so I have an alternative suggestion: embeddable
Emacs in Scheme!  Such a system would have two parts:


	1. An full implementation of elisp in Scheme.

	2. Abstractactions around the elisp interpreter to give emacs
	   an `outside' that is accessible from Scheme.


When I say ``give emacs an `outside','' I mean something like this:
Imagine a scheme data structure type called EMACS-SESSION.  An
EMACS-SESSION would have several component parts: a collection of
buffers, a set of redisplay hooks, and controls for an instance of an
elisp interpreter.  It would be possible to examine and modify buffers
and elisp environments from the Scheme side.  There is really no need
to expose the Scheme side to the elisp side.

It should be possible to instantiate more than one EMACS-SESSION
object at a time.  In addition, it should be possible to move buffers
between sessions.  These features will allow one to get the benefits
of a multi-threaded Emacs -- when a slow command is executing, the
emacs-session can `fork' into one busy and one responsive session.
After the slow command is done, the two sessions can `join' back into
one.

I can see a few strategies for implementing elisp in Scheme.  The
Right Thing might even be a combination of these strategies:

	- source to source translation
		This has been tried before, but i don't know the reference.
		My recollection is that not all code could be successfully
		converted -- but the goal (as i recall) was to convert
		elisp to edwin scheme, rather than to implement
		elisp semantics faithfully.  Just reimplementing elisp
		might be simpler.

	- reimplement the elisp bytecode machine
		This would probably be too slow.

	- choose a VM based Scheme, and write an elisp front end for it
		My personal favorite.  It may also be possible
		to code an elisp VM in Scheme without giving up
		too much performance.  If nothing else, that would
		be a good way to prototype the VM.


Component parts for a buffer data structure, keymaps, event loops
etc. can be found in Edwin or in some code that I have.

I think an implementation of EMACS-SESSION would be an excellent
addition to Scheme based user interface toolkits like Stk (or the one
i'm writing ;-).  It might also be nice for people who use Scheme on
systems that don't conveniently run Emacs at the same time.

On the off chance that somebody is interested in trying to do this,
please send me some email.

-t
