Path: utzoo!mnetor!uunet!husc6!bbn!rochester!daemon From: miller@ACORN.CS.ROCHESTER.EDU (Brad Miller) Newsgroups: comp.ai Subject: Re: Explorer (vs. Sun) Experience ? Message-ID: <9457@sol.ARPA> Date: 7 May 88 01:43:28 GMT Sender: daemon@cs.rochester.edu Lines: 47 Date: 5 May 88 19:13:15 GMT From: jeff@aiva.ed.ac.uk (Jeff Dalton) [...] I would think you could just call a built-in function, etc. This seems more a question of what libraries are available than an inherent advantage of Lisp machines. I think the more telling difference is your ability to change under a lispm environment what is taken as immutable under UNIX. For example, if I want to modify the scheduler slightly, I can do that *at runtime*, I don't have to compile a whole new system to run. If I want to change a definition being used in another process, again, I can change it *at runtime*. Thus, I can write new modes for my editor, and test them out in the same session, not reload and relink a new version of the editor and then test *that* out. In general, one is provided with the source to the entire system, and any function may be changed or advised (advice is giving a piece of code to be run before, after, or around some definition. Thus if I don't want to actually change some part of the compiler because it will change between releases, but the interface will remain constant, I can advise it instead. Since advice can be compiled, there is really no performance penalty to doing this, it is a function of working on an object-oriented system. Most importantly, a lispm does not distinguish between the 'user' and the 'kernel'. Everyone is one big happy address space. This has the advantage of allowing you to reuse software as you see fit, not as some UNIX designer has decreed your interface must be to the kernel. You are free to call directly or modify any functions that would normally be inside of the kernel, e.g. the scheduler example I brought up. Why write your own scheduler to run as a single UNIX process when you can just modify your system's scheduler to suit? There are many other advantages to the lispm environment, but I'm just attempting to address this issue of libraries. Several papers have been published on the lispm programming environment(s), the more current of which I'm sure e.g. Symbolics will be happy to provide you with. As a quick starter, look at _Interactive Programming Environments_ by Barstow, Shrobe, and Sandewall, but realize that the book was published 4 years ago, and all of Xerox, TI and Symbolics have done much to advance the state of the art since then. ---- Brad Miller U. Rochester Comp Sci Dept. miller@cs.rochester.edu {...allegra!rochester!miller}