dankg@lightning.Berkeley.EDU (Dan KoGai) (05/30/90)
In article <13831@csli.Stanford.EDU> poser@csli.stanford.edu (Bill Poser) said: > >Yes, the original EMACS was a set of TECO macros. But no, non-TECO versions >of EMACS did not start with ports to micros. The earliest ones were >written in LISP. James Gosling then did an EMACS in C, now sold by >UniPress. And then Richard Stallman, who did the original EMACS, >wrote GNU EMACS. See: > 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. 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). ---------------- ____ __ __ + Dan The "fun to see emacs running emacs inside" Man ||__||__| + E-mail: dankg@ocf.berkeley.edu ____| ______ + Voice: +1 415-549-6111 | |__|__| + USnail: 1730 Laloma Berkeley, CA 94709 U.S.A |___ |__|__| + |____|____ + "What's the biggest U.S. export to Japan?" \_| | + "Bullshit. It makes the best fertilizer for their rice"
poser@csli.Stanford.EDU (Bill Poser) (05/30/90)
In article <1990May30.052145.15392@agate.berkeley.edu> dankg@ocf.Berkeley.EDU (Dan Kogai) writes: > Now I have a question: Why did Richard Stallman chose lisp out of >others? Why wasn't it C or anything? Stallman discusses the choice of language in the paper I cited in my previous message in sections 4 "Extensibility and Interpreters" and 5 "Language Features for Extensibility". The most important consideration is the ability to redefine just about everything at run time, which is absent in most compiled languages. For example, part of the time I use Epsilon, which is a very nice EMACS clone with an extension language very close to C. I like this, as I too prefer C, most of the time. But you have to recompile after making most changes, and I find that this discourages me a bit from making changes. Another factor that Stallman cites is the availability of dynamic scope. I don't find his argument for this very persuasive, but he does and so it affected his choice. Bill
pierson@encore.com (Dan L. Pierson) (05/30/90)
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
rlk@think.com (Robert Krawitz) (05/31/90)
In article <1990May30.052145.15392@agate.berkeley.edu>, dankg@lightning (Dan KoGai) writes:
] 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.
Most likely because he was most familiar with Lisp. Another very good
reason is that lisp supports dynamic memory allocation and lists very
nicely, much better than C/pascal (in C you need to do all the list
manipulation yourself). Shell scripts are powerful, but it's not a
complete language without all the Unix tools (sed, awk, grep, etc.).
Lists are useful more often than you might expect for an editor; rmail
would be a real headache to implement without them.
] 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 possible to link in executable code on at least some
architectures; Lucid lisp supports a "foreign function" interface that
lets you link in objects and even libraries at run time. On the other
hand, it's messy too.
Garbage collection's the price you pay for not having to do memory
allocation yourself. Having to do memory allocation in an emacs script
wouldn't be much fun.
BTW, many of the core functions are in fact written in C (something like
500, I recall). It's surprising how many functions would not be faster
in C, though.
--
ames >>>>>>>>> | Robert Krawitz <rlk@think.com> 245 First St.
bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142
harvard >>>>>> . Thinking Machines Corp. (617)876-1111