Text File

Aucbvax.4940 fa.editor-p utzoo!decvax!ucbvax!editor-people Tue Nov 3 11:36:23 1981 LISP >From DLW@MIT-AI Tue Nov 3 11:24:16 1981 When you set out to write an editor, your first and most important decision is the language in which to implement the editor. Several people have implemented major text editors in Lisp, and many of us belive that Lisp is ideally suited to text editors. Our discussion of Lisp is therefore quite appropriate for this mailing list. Those of you who disagree should feel free to delete this message without reading further.

In his recent mail, cbosgd!mark@Berkeley stated that "Lisp does not provide any built-in advantages for a real language editor." It appears to me that he is not familiar with the language that Lisp has turned into, at MIT as well as other places.

First of all, he attempts to rebut the statement that Lisp supports records just as Pascal does. He challenges us with a long series of if's, as if to suggest that Lisp's support of records is conditional on many unlikely things. Let's take a look at these if's.

So basically what you're saying is that if you have one of the LISPs you mentioned with arrays (I wonder what "Standard LISP" is?), True; you do need to have a Lisp with arrays. All major dialects of Lisp support arrays. and if you're willing to use a macro that makes a record reference look like a function, Sure, I'm willing. There's nothing very iffy about it. Is Mark "willing" to use records in Pascal? Why not use such macros? and you're willing to give up any compile time or runtime type checking, I will discuss the complex issue of type-checking later. and if you have a compiler that is very smart about handling array references with constant subscripts, then you can get something that works as well as a dumb Pascal compiler would produce. Why should a Lisp compiler have to be "very smart" to produce code that works as well as a "dumb" Pascal compiler? A real Lisp implementation must be designed carefully to allow efficient implementation of arrays, but no particular complexity in the compiler is needed that a Pascal compiler would not need.

You can add features to any language, Mark scoffs. Apparently because records were "added" to Lisp at some point during its history, rather than having been there in the first place, they are somehow are not as good as Pascal records. The logic here escapes me.

Actually, you can't add features to any language nearly as easily as you can add them to Lisp. If you purchased a Pascal compiler that did not support records and you wanted to add them, you would have a tough job ahead of you; you'd have to modify the compiler's parser, data structures, and code generator. Probably you have never figured out how the compiler works; you might not want to put in that much effort; you might not own the sources; you might not know much about compilers. In Lisp, you can just write a macro, and before records were added to the language, many people tried out several different schemes for records; users would extend the langauge to include records, easily and efficiently, by using Lisp macros. After some time, the implementors of Lisp Machine Lisp chose one scheme taht seemed to work best, and integrated it into the language as a standard feature.

Such language extensibility is important to large systems programs like text editors. The major editors written in Lisp use macros in powerful and elegant ways to extend Lisp into a more specialized language for writing editors. This is one of the main reasons that Lisp is well-suited for text editors.

Mark says: I used LISP as the language for writing attribute grammar evaluation functions in my thesis, because I could write an interpreter for in quickly (I spent 4 days on it).

It is a well-known myth that Lisp is very simple and can be implemented in a few days. Indeed, it is quite possible to create a "toy Lisp" (as we call them) in only a few days, and toy Lisps are indeed useful for smoe applications, like Mark's. However, this is NOT what we are talking about when we talk about using Lisp to write text editors. A real, modern Lisp system must be carefully designed and implemented. A group of about three experts, working full-time, could reasonably be expected to produce a realistic Lisp implementation in about a year. I speak from my knowledge of recent experiences with several new Lisp implementations for the VAX; it took many more man-years to get the Lisp Machine's dialect (Zetalisp) where it is today.

The major Lisp-coded Emacs-like editors are Zwei (written for the Lisp Machine by me), Multics Emacs (written by Bernie Greenberg for Multics), and Nile (written by Richard Soley for the VAX NIL dialect). Major Lisp implementations of the Maclisp family include ITS Maclisp, Multics Maclisp, Zetalisp (the Lisp Machine dialect), and the two implementations of the NIL dialect for the VAX and the S-1 (these two are not complete but they are working to some extent). Franz Lisp for the VAX may count too (I'm not sure), and the CMU Spice Lisp will count when it is implemented. The NILs, Zetalisp, and Spice Lisp will be upward-compatible subsets o Common Lisp, a large common subset in which a portable Lisp editor could be built.

(I am too flamed out to get to the issue of data typing; some other time...)

----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen <jgoerzen@complete.org> of http://communication.ucsd.edu/A-News/

This Usenet Oldnews Archive article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.