Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!snooze.UUCP!layer
From: layer@snooze.UUCP (Kevin Layer)
Newsgroups: comp.lang.lisp
Subject: Re: Unix Lisp Environments (why the slow evolution)
Message-ID: <8905111806.AA05209@snooze>
Date: 11 May 89 18:06:22 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 81

Brad,
  Yes we have *true* stack groups which share everything (but stack,
obviously)--there is one UNIX process.  All the features of our
debugger work generally on any `lightweight lisp' process (LLP), which
means you can return, restart, examine locals, etc.  In fact, Allegro
Common Windows uses one LLP for each window.  

>> Can I invoke the editor based on the current stack frame?

I'm not familiar with this feature (maybe if I were we would do it).

>> Examine lexical closures not currently on the stack?

Closures can be inspected just as functions can be.

>> Examine open catch tags? error tags? 

Yes.  What are "error tags"?  If this has to do with the (kmp's)
condition system, then the answer is that we fully support version 18.

>> applicable CLOS before/after/primary methods? 

We don't have a CLOS browser, but it is on our list for version 2 of
Allegro Composer.

>> 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? 

If you mean can we search back up the stack for an object and set the
frame point to that frame, well, now that you mention it that sounds
pretty handy and easy to do.  I've just put it on our "request for
enhancement" list.

We don't currently have "watch points", but I admit it would be nice.

>> 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).

For objects that have print/read consistency, we have an inspect which
will do what you want.

Regarding source code, yes, we do license it.  And yes, if you have
source code you may redefine the scheduler.  Even without source, you
can advise any function to change its behaviour.

>> 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)?

When version 19 of GNU Emacs is available, then all your interaction
with Lisp could be through type-in windows managed by X11/GNU Emacs.

The integration between GNU Emacs and Lisp is tight, as I said.  Most
everything one does in the interface is transparent, *except*
customizing the editor.  If you spend a lot of time doing this, then
this might be a drawback.

>> 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).

Our reader does backup and re-read expressions so that reader macros
are handled correctly--this is done by Allegro Common Windows.

>> 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.

We have v18 of the condition system, CLX (highly optimized), and CLOS.
I think you'll find the performance of Allegro CL on RISC processors is
quite amazing.  If that isn't enough, we're on the Cray.

	Kevin Layer
	Franz Inc.