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 <
[email protected]>
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.
