Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bbn!rochester!daemon
From: miller@CS.ROCHESTER.EDU (Brad Miller)
Newsgroups: comp.lang.lisp
Subject: Re: Unix Lisp Environments (why the slow evolution)
Message-ID: <1989May11.013529.11949@cs.rochester.edu>
Date: 11 May 89 05:35:29 GMT
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 59

I really wasn't going to post anything more on this stuff, but oh hell.
There are no flames in this article. I'm only, AS ALWAYS, Seeking knowledge.

    Date: 11 May 89 01:03:36 GMT
    From: layer@snooze.UUCP (Kevin Layer)

	The biggest problem we still face is debugging a multiprocessing lisp
	using emacs only (we dont like sunview--OK!).  It would be nice to have
	a facility like the lucid editor provides in good old gnu emacs.

    Again, we have almost reproduced a Lisp machine environment using just
    GNU Emacs.  The `almost' comes from the fact that the interpreter for
    Emacs and Lisp are different (and always will be), so you must write
    editor programs in Emacs Lisp and everything else in Common Lisp.  I'm
    not sure what problems you are talking about here, but our debugger
    allows the interactive debugging of a process in one window from
    another.

OK I'll bite and would appreciate your response (I'm used to lispms; only
non-lispm CL I can currently compare to is KCL - an environment-free lisp
:-)

Can you handle >1 lisp process running in the same (shared) address space?
That is, are there stack groups and coroutining? Dynamic Closures (basically
a stack group not run in a separate process)? Can I indeed debug a running
process from another process in a different window (examine vars, etc. while
the thing runs)? Can I invoke the editor based on the current stack frame?
Examine lexical closures not currently on the stack? Examine open catch
tags? error tags? applicable CLOS before/after/primary methods? Upon
signalling an error in a bad argument to some instruction, can the debugger
move the stack immediately to the frame that originally passed the bad value
(presumably up the stack via parameters, but possibly via a dynamic
binding)? How about invoking the debugger when a var is rebound? written to?
read? Can I mouse click on anything printed in the window and examine it's
underlying representation? (a list may print as (A B #) but is really
something else, also for, e.g. structured objects with print methods).

And, since this is almost a lispm environment modulo the emacs lisp
language, can I incrementally compile a new scheduler and have it work on my
workstation? What about other parts of the system? Full sources provided? In
Lisp? My primary input editor to any window Emacs (I do so hate to have to
reimplement the world to provide decent input editing to the user when I
want to accept data)? The point here is that real hackers want the universe
essentially part of the language, not a separate OS. The lispms give you
that - and that's what I want from anyone claiming to be giving me
"essentially a lispm environment".

Last time I looked seriously at the non-lispm lisp market was 18 months ago,
and it was clear then that the lispm was worth the money, mainly because of
the debugger, but also because of these other issues I've touched on. There
also seemed to be serious problems if the user defined "interesting" reader
macros when the system handled rubouts. (Like, it didn't correctly undo/redo
the functions the macros called). If you can give me that, with the
"approved" CL extensions (error system, CLX, CLOS) and at least 3620 level
performance without 3620 cost (2mw, 380mb = $20k) - your system starts
becoming quite a viable alternative.

"A lispm chauvinist with an open mind" (oxymoron of the month club selection
:-),