[comp.lang.scheme] Lisp vs. Scheme Emacs

jameson@cpsc.ucalgary.ca (Kevin Jameson) (11/23/88)

Why is Lisp used in GNU Emacs (and in the rest of the Emacs family)
in preference to Scheme?  Or phrased another way, would there be
any significant advantages/disadvantages to basing an editor on
Scheme instead of Lisp?

Thanks
  Kevin

jbs@fenchurch.mit.edu (Jeff Siegal) (11/24/88)

In article <237@cs-spool.calgary.UUCP> jameson@cpsc.ucalgary.ca (Kevin Jameson) writes:
>[...] basing an editor on Scheme

There is an editor called EDWIN, which is an Emacs look-alike, not
only based on Scheme, but written entirely in it.

Jeff Siegal

pk@tut.fi (Kellom{ki Pertti) (11/29/88)

In article <237@cs-spool.calgary.UUCP> jameson@cpsc.ucalgary.ca (Kevin Jameson) writes:
>Why is Lisp used in GNU Emacs (and in the rest of the Emacs family)
>in preference to Scheme?
As I understand it, GNU Emacs Lisp has been written solely for the purpose of
writing text editors. It has some really nice features for doing that, whereas
it lacks some features that more general purpose lisps have (closures among 
others). The primitive editing functions of GNU Emacs Lisp have been written 
in C, so they are pretty fast. The thing I am personally most impressed about
GNU Emacs Lisp is how easy it is to manipulate buffers, windows etc. from Lisp
code. 
-- 
Pertti Kellomaki  (the 'a' with an umlaut)       Tampere Univ. of Technology
+358 31 640 550    home                             Internet: pk@tut.fi
+358 31 162 934    work (L406)                          UUCP: tut!pk

wilson@uicbert.eecs.uic.edu (12/01/88)

On the other hand, in Stallman's paper on EMACS, he says that it
exploits dynamic binding for flexibility.

Is the Scheme version (Edwin) as elegant as the Lisp version?  Does
it fake dynamic or fluid binding explicitly?

kjell@saturn.ucsc.edu (Kjell Post) (12/02/88)

In article <82000004@uicbert.eecs.uic.edu> wilson@uicbert.eecs.uic.edu writes:
>
>On the other hand, in Stallman's paper on EMACS, he says that it
>exploits dynamic binding for flexibility.

How can a *bug* be considered flexible?

(Boy, am I in trouble now...)
-- 
      For athletes and programmers,  ! Kjell E. Post
a woman is the end of their career.  ! CIS/CE
                                     ! University of California, Santa Cruz
              -- A.Wickberg          ! Email: kjell@saturn.ucsc.edu

nosmo@vision.ucsb.edu (Vincent Brooke Kraemer) (12/03/88)

Forgive my stupidity on this answer - but wasn't EMACS originally written in
Lisp, like way way back. (i.e. before we were scheme'ing)

I am sure that you can write an EMACS in just about any language you want -
but do you really want to ignore a considerable amount of work that has
already been tried and worked.  The decision was probably made more on the
basis of intelligent software engineering practice than religious beliefs. Or
at least  I would hope so.
-------------------------------------------------------------------------------
I only .sig in "soc." groups - real news doesn't need it.

Alan@AI.AI.MIT.EDU (Alan Bawden) (12/04/88)

    Date: 2 Dec 88 06:42:46 GMT
    From: agate!saturn!kjell@labrea.stanford.edu  (Kjell Post)
    How can a *bug* be considered flexible?  

The original Scheme papers by Sussman and Steele contain some good
arguments for why dynamic variables are sometimes exactly what you want.

    Date: 3 Dec 88 01:05:58 GMT
    From: ucsbcsl!vision!nosmo@bloom-beacon.mit.edu  (Vincent Brooke Kraemer)
    Forgive my stupidity on this answer - but wasn't EMACS originally written in
    Lisp, like way way back. (i.e. before we were scheme'ing)

No, the original EMACS was written in TECO.  (And in case you are
wondering, TECO is dynamically scoped.)

cph@KLEPH.AI.MIT.EDU (Chris Hanson) (12/07/88)

   Date: 30 Nov 88 23:53:00 GMT
   From: uxg.cso.uiuc.edu!uicbert.eecs.uic.edu!wilson@uxc.cso.uiuc.edu

   On the other hand, in Stallman's paper on EMACS, he says that it
   exploits dynamic binding for flexibility.

   Is the Scheme version (Edwin) as elegant as the Lisp version?  Does
   it fake dynamic or fluid binding explicitly?

As the author of Edwin, here's my "definitive" answer:

Naturally I believe that Edwin is as elegant as GNU Emacs; since half
the fun I get out of writing a program is making it elegant, I did my
best to accomplish this.

In some ways, it is less elegant: in particular, because Edwin was
about half built before I ever saw or played with GNU Emacs, many
parts of it are based on the original Emacs (most of the documentation
strings were snarfed directly from the TECO source code).  Once I
found out about GNU Emacs, the design changed direction midstream, and
subsequent developments more closely mirror the GNU model.  Future
work is likely to close the gap with GNU Emacs even more.

In other ways, I feel that it is more elegant: the programming model,
unlike GNU Emacs, fosters "object manipulation" rather than "editing
steps".  By this, I mean the following: GNU Emacs (like Multics Emacs)
encourages the extension writer to view the activity of writing
extensions almost like that of writing keyboard macros; e.g. there is
always a current buffer, you switch buffers to change things in other
buffers, and there are a variety of things like `save-excursion' to
allow you to remember where you were in various ways.  In other words,
many of the side effects that an extension performs are incidental
rather than essential.  Edwin encourages you to think like a
programmer: you've got alot of objects lying around, and you
manipulate the objects directly; incidental side effects are
unnecessary, because there are no (or perhaps only a few) dependencies
on the current state.  For example, if you want to change a buffer
other than the current one, you just get a pointer to it and
manipulate it using the usual mechanisms, which all accept buffers as
arguments.

Of course, judging elegance in this way is pretty artificial.  Both of
these programming models are elegant in different ways.  GNU Emacs'
programming model is elegant because it is similar to the model of the
Emacs user.  Edwin's is elegant because distinguished objects play a
much smaller role, and certain kinds of programming abstractions are
easier to capture; also it is similar to the way that programmers
think (i.e. lots of objects, and side effects on those objects).

Finally: Edwin does GNU Emacs one better in the dynamic binding
question, because MIT Scheme has dynamic binding.  Edwin uses dynamic
binding where it is appropriate, and the rest of the time it relies on
lexical scoping.