Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!ut-sally!utah-cs!utah-orion!shebs
From: shebs@utah-orion.UUCP (Stanley T. Shebs)
Newsgroups: comp.lang.lisp
Subject: Re: A Decent Environment. Where is it? (some flame, some advice)
Message-ID: <179@utah-orion.UUCP>
Date: Wed, 11-Nov-87 20:30:29 EST
Article-I.D.: utah-ori.179
Posted: Wed Nov 11 20:30:29 1987
Date-Received: Sat, 14-Nov-87 05:01:55 EST
References: <21493@ucbvax.BERKELEY.EDU> <2630001@hpfcmp.HP.COM>
Reply-To: shebs@orion.utah.edu.UUCP (Stanley T. Shebs)
Organization: PASS Research Group
Lines: 70

In article <11639@think.UUCP> barmar@sauron.UUCP (Barry Margolin) writes:

>[...]  I don't think there
>are any Unix debuggers that even come close the Symbolics Lisp Machine
>debugger.  Unix is twice as old as Lisp Machines, and you'd think that
>with all the zillions of lines of C code that have been written for
>Unix there would be some really amazing debuggers by now.  On the
>contrary, I suspect that there are still a large number of Unix
>programmers using adb, not even source-level debugging.

You have a good point.  But consider that a high-level debugger must know
about the language implementation, and therefore be different for each.
The Symbolics debugger is only useful for official Symbolics languages.
If I were to, say, port PSL to a Symbolics, the pre-existing debugger would
be quite useless.  Unix systems run a great variety of languages.  There are
C debuggers out there, but C is a very low-level language, and it's quite
easy for a C program to trash things so badly that the symbolic debugger's
own data structures are destroyed.  Adb has the advantage that it *almost*
always works (although I've been in situations in Lisp implementation work
where even adb couldn't fathom what had happened...).

Now if one were to take a tools-oriented approach to debugging, there would
be a small language/interface to specify types of debugging actions, the state
of execution would be available as a normal data object to be looked at, the
user interface would be separate from the basic breakpoint/examine/step code,
and the debugger would have a published interface to the language system,
so that a conforming language would be usable with that debugger.  Even
Lisp machine debuggers haven't managed all that yet (unless there's an
amazing new one I haven't heard about?).

>>A tool-oriented Lisp environment would
>>presumably use S-expressions as the basic interface, although one would
>>probably need some sort of lazy version, so that heap space isn't exhausted
>>by the creation of one intermediate object.  
>
>I don't understand this point.  I create lots of intermediate objects
>all the time while debugging and prototyping in Lisp.

To take a realistic example, I've been having to debug some subtle misbehavior
where I'm not quite sure what exactly is wrong.  I've been applying pipes of
Unix tools (grep mostly) to a 1-2 megabyte log file, trying to get a feel for
patterns in it.  Even a Lisp machine has a hard time dealing with dozens of
ephemeral objects each several megabytes in size...  To take another example,
Aho, Sethi, and Ullmann formatted the multi-megabytes of their compiler book
with a long pipe of various tools. (no, I'm not defending troff!)

>>					      Useful operations include
>>many already in Common Lisp, such as sorting, set operations, and reversing,
>>but extended to operate on incompletely-defined things.  
>
>Most of these operations are generalized to some extent in Common
>Lisp; in my view, this was one of its most significant innovations.
>[...]

I'm all too familiar with CL sequence functions and their innards! :-) :-(
Nevertheless, they must conform to Lisp's strictness - the arguments are
completely evaluated before the operation starts.

In general, I was suggesting a research program rather than demanding a 
particular kind of Lisp environment.  Certainly it's not reasonable to make
Lisp look like Unix or APL or EZ!  On the other hand, although Lisp people
might once have had the lead in environments, not much has happened in recent
years, and people working in conventional languages are catching up fast.
It's disappointing to see a defense of the status quo rather than new ideas.

>Barry Margolin
>Thinking Machines Corp.

							stan shebs
							shebs@cs.utah.edu