Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!KLEPH.AI.MIT.EDU!cph From: cph@KLEPH.AI.MIT.EDU (Chris Hanson) Newsgroups: comp.lang.scheme Subject: Lisp vs. Scheme Emacs Message-ID: <8812070255.AA00972@kleph.ai.mit.edu> Date: 7 Dec 88 02:55:08 GMT Sender: daemon@bloom-beacon.MIT.EDU Reply-To: cph@zurich.ai.mit.edu Organization: The Internet Lines: 54 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.