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}