Xref: utzoo alt.folklore.computers:3534 comp.emacs:8378 gnu.misc.discuss:1053 Path: utzoo!attcan!uunet!mailrus!ncar!husc6!encore!pierson From: pierson@encore.com (Dan L. Pierson) Newsgroups: alt.folklore.computers,comp.emacs,gnu.misc.discuss Subject: Re: Why Lisp? (Was: Re: Remember how great editors used to be?) Message-ID: Date: 30 May 90 14:11:54 GMT References: <7572@tekgvs.LABS.TEK.COM> <13829@csli.Stanford.EDU> <12602@netcom.UUCP> <13831@csli.Stanford.EDU> <1990May30.052145.15392@agate.berkeley.edu> Sender: news@Encore.COM Followup-To: alt.folklore.computers Organization: Encore Computer Corporation Lines: 75 In-reply-to: dankg@lightning.Berkeley.EDU's message of 30 May 90 05:21:45 GMT On 30 May 90 05:21:45 GMT, dankg@lightning.Berkeley.EDU (Dan KoGai) said: > Now I have a question: Why did Richard Stallman chose lisp out of > others? Why wasn't it C or anything? A lot of script|macros on other > applications are more C|pascal-like language. Shell script is so, tmw is so, > and a lot more. Probably because he was a long-time Lisp hacker who was well aware that several very successful Emacsen had been implemented in Lisp (e.g. Multics Emacs, Zmacs). > I found elisp very powerful and elisp alone is complete computer > language. But I personally don't like LISP--I hate bunch of ()'s. And it > does gabage collection like hell when large elisp program is invoked, such as > gnus. It could've been tighter if external commands are written in C and > the editor loads the objects (can it be done without linking? Macintosh > can just by loading it as resource file. Or maybe invoke it as different > session but it would be not a good idea). It is easy to come up with an sort of C or Pascal like language instead of Lisp. Gosling did it with MockLisp (he just used lots of parenthesis :-)), Epsilon and recent versions of Brief do it with C, DEC'S TPE does it with Pascal. I was looking at some Brief system macro code recently and was amazed how much it looked like MockLisp; all the function names looked the same, the control flow was very similar, etc. The only real difference was the syntax and keywords; I suppose this sort of thing is a big deal to some people... The most important thing in an extension language is that it be very flexible, modifiable and efficient enough. In particular: it has to support high-level datatypes such as buffers, windows, and keymaps; it has to link functions at call time so that lower level behavior can be customized (a real advantage of symbol function values); and it has to support function-valued hook variables. It is very useful if the syntax support these features is as concise and readable as possible. A full interpreted mode also helps; both for debugging and quick interaction without a compile cycle. The real advantages of Lisp as opposed to one of the above languages are the traditional data structures and features of Lisp. For example, alists (e.g. auto-mode-alist) are an extremely convenient way to create and manipulate the sort of pattern matching lookups common in Emacs extensions (look at the old Gosling auto-mode code if you don't agree, Unipress seems to have moved this particular case to a built-in function). Real C (or Pascal, etc.) fails to meet several of the above goals: since function calling is fixed at link time, lower level behaviour can't be changed without relinking the entire Emacs and bugs in dynamically loaded code can't be fixed without starting over in a new Emacs; and since C doesn't understand datatypes more complex than numbers and structures, editor support code will be comparatively verbose, hard to read, and slow to write. GNU Emacs is far from perfect in these areas. Parts of the editor are written in C and cannot be modified without recompiling and linking the whole thing (at a cost in disk space and complexity that many users cannot afford). Modifying low level functions is harder than it needs to be; a decent object-oriented Lisp would help a lot here, even a built-in advice facility would be an inprovement. On the whole though, GNU Emacs is, IMHO, a very good compromise with the realities of the mid to high end of the current Unix computing world. If you want to write a new Emacs with a different extension language, I'd strongly suggest looking at a moderately high-level, object-oriented language with dynamic inheritance and whatever syntax you prefer. -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@encore.com