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
pierson@encore.com (Dan L. Pierson) (05/31/90)
About Emacs extension languages. On 30 May 90 14:11:54 GMT, pierson@encore.com (Dan L. Pierson) said: > 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. I was thinking about this a bit more over lunch and came up with a truely horrible idea for all the Lisp haters out there: !!!! PLEASE, DON'T ANYONE ACTUALLY DO THIS !!!! But, just for the fun of it, think of an Emacs based on Perl instead of Lisp... You'd have to add a redisplay command, buffer and window data structures with associated magic (should either of them be accessed as filehandles?, arrays?). A special keymap structure might be useful, but could probably be dispensed with. Regular expression support and functions are already there. Incremental compilation and loading would be needed. X support... What else? -- 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-1111gudeman@cs.arizona.edu (David Gudeman) (06/01/90)
In article <PIERSON.90May30143529@xenna.encore.com> pierson@encore.com (Dan L. Pierson) writes: >About Emacs extension languages. >... >But, just for the fun of it, think of an Emacs based on Perl instead >of Lisp... What about doing one in SNOBOL4? It has patterns (more general than regular expressions) and the facilities necessary to read in and execute new code at run-time. Even more fun, SNOBOL4 has goto's, and it is possible for a running SNOBOL4 program to read and execute a piece of SNOBOL4 code that has a goto to some label in the main program. Wow. There might be a slight performance penalty associated with the way SNOBOL4 stores strings, they are all kept in a symbol table... -- David Gudeman Department of Computer Science The University of Arizona gudeman@cs.arizona.edu Tucson, AZ 85721 noao!arizona!gudeman
rodney@ipl.rpi.edu (Rodney Peck II) (06/01/90)
gudeman@cs.arizona.edu (David Gudeman) writes: >In article <PIERSON.90May30143529@xenna.encore.com> pierson@encore.com (Dan L. Pierson) writes: >>About Emacs extension languages. >>... >>But, just for the fun of it, think of an Emacs based on Perl instead >>of Lisp... >What about doing one in SNOBOL4? It has patterns (more general than >regular expressions) and the facilities necessary to read in and >execute new code at run-time. Even more fun, SNOBOL4 has goto's, and >it is possible for a running SNOBOL4 program to read and execute a >piece of SNOBOL4 code that has a goto to some label in the main >program. Wow. The evil editor on th Michigan Terminal System (MTS) which runs on IBM mainframes in nearly 8 different places in the world (RPI being one of them) is based on snobol. It might be nice except that being an ibm mainframe, everything is record orientated instead of character orientated so editing with keyboard mapping is not really feasable (at least they haven't bothered to try it out). So, you get to use this really awful editor on old rackety ibm 3270 consoles. Yuck. -- Rodney
jem@hpisod2.HP.COM (Jim McCauley) (06/05/90)
At 11:35 am May 30, 1990, pierson@encore.com (Dan L. Pierson) wrote: > But, just for the fun of it, think of an Emacs based on Perl instead > of Lisp... This is only a moderately terrible idea. If it led to the practice of Un*x users consistently using an editor as their shell, it couldn't be entirely bad. The members of my documentation team are nearly all ksh users, perdominantly due to the interactive command-line editing feature. Jim McCauley jem@hpulpcu3.hp.com (408) 447-4993 Learning Products Engineer Hewlett Packard Company, General Systems Division MS 48SO, 19447 Pruneridge Avenue, Cupertino CA 95014 Disclaimer: My opinions are my own, not my employer's.
merlyn@iwarp.intel.com (Randal Schwartz) (06/08/90)
In article <13920007@hpisod2.HP.COM>, jem@hpisod2 (Jim McCauley) writes: | At 11:35 am May 30, 1990, pierson@encore.com (Dan L. Pierson) wrote: | | > But, just for the fun of it, think of an Emacs based on Perl instead | > of Lisp... | | This is only a moderately terrible idea. If it led to the practice of | Un*x users consistently using an editor as their shell, it couldn't be | entirely bad. The members of my documentation team are nearly all ksh | users, perdominantly due to the interactive command-line editing feature. As much of a Perl fanatic as I present myself as, I kinda like having a lisp-like language be the underpinnings of my shell, er, Emacs. I invoke an emacstool once per day on each machine in this net that I'm going to be using. (I hardly ever invoke just a shelltool.) I live inside Emacs, firing off (sometimes multiple) shell windows from the Emacs. For example, right now, I'm typing this message on an Emacs 'gnews' window running on iwarpsa (a sparc) that I've logged into from iwarpj0 (the diskless Sun3 on my desk), and I'm reading and replying to mail in another emacstool on iwarpj (a sun3 that handles my mail). When I need to do a command, I invoke 'background-shell' in the appropriate emacs window. From home, I log in with my Hayes V.32 modem (19.2Kbaud), and immediately invoke an Emacs... this gives me windows at home. And, it's the same interface as what I have at work. So all my tools and keystrokes are the same. Why have a shell prompt? Just another Emacs hacker (and Perl hacker), -- /=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\ | on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III | | merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn | \=Cute Quote: "Welcome to Portland, Oregon, home of the California Raisins!"=/