Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!solaris.cc.vt.edu!uunet!news.cygnus.com!nntp!lord
From: lord@cygnus.com (Tom Lord)
Subject: Re: Emacs in Scheme!
In-Reply-To: tthorn@ceres.daimi.aau.dk's message of 12 Sep 1994 19:28:03 GMT
Message-ID: <LORD.94Sep13192551@cygnus.com>
Followup-To: comp.lang.scheme
Sender: news@cygnus.com
Nntp-Posting-Host: cygnus.com
Organization: Cygnus Support
References: <LORD.94Sep10220125@x1.cygnus.com> <TTHORN.94Sep12212804@ceres.daimi.aau.dk>
Date: Wed, 14 Sep 1994 02:25:49 GMT
Lines: 57


In reply to me, tthorn@ceres.daimi.aau.dk (Tommy Thorn) writes:

				       it will be tedious to make the new
    > Scheme-based abstractions work as well as elisp on both graphics and
    > ascii terminals;

   ?? Why? I run Scheme on ascii terminals just fine. I even run Scheme
   on underpower machines (= 4Mb) sans probleme.


Some context was lost.  I meant that it would be tedious to define 
a library of Scheme functions that, like Emacs, obscured whether the
system was running on an ascii or a graphics terminal.  The decision 
to support both kinds of display permeates the design of Emacs.  There 
is no reason why similar design decisions can't be made for a Scheme
based system -- the point was simply that it would take a lot of work
just to catch up to Emacs.


		       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.

   It shouldn't be a problem to allow two views on the world.

I agree, hence my suggestion:

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

   This is of course the "right way", but it requires much more work.

I disagree that this approach require more work.  The hidden cost of
Scheme-in-Emacs is the work it would take to make the Scheme
implementation practical for non-trivial programs.  Most of the data
structures for Emacs-in-Scheme already exist, so that route isn't
as expensive as it might look at first.


    > 	   - reimplement the elisp bytecode machine [in scheme]
    > 		   This would probably be too slow.

   Not if the scheme had a resonably good native code compiler.

   All this sounds very much like edwin. Wouldn't edwin be a natural
   place to start? Has anyone ever tried to implement the Emacs VM
   in edwin?


I believe that someone at MIT wrote a translator that was good enough to
convert dired.el to Edwin Scheme.  I'll bet i saw this either thomping
around on altdorf or in the Scheme repository at indiana, but i really don't
recall for sure.

-t

