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: <180@utah-orion.UUCP>
Date: Fri, 13-Nov-87 18:53:06 EST
Article-I.D.: utah-ori.180
Posted: Fri Nov 13 18:53:06 1987
Date-Received: Sun, 15-Nov-87 16:39:53 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: 84

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

>Only if you choose not to put the effort into your port to make it
>generate Symbolics standard functions.  [...]
>Of course, it goes without saying that you should follow Symbolics's
>stack discipline.

The reason I mentioned PSL specifically is that it uses a register protocol
instead of a stack protocol.  That's what I meant about environment designers
not being clever enough to anticipate what programmers will come up with.
It shouldn't "go without saying" that I have to implement my languages the
way somebody else implemented theirs.  After all, the whole point of higher
level languages is to allow different implementations!

>Before I was a Symbolics user I was a Multics user.  In Multics, the
>entire runtime environment is standardized across all languages
>(except some esoteric ones like MacLisp and SNOBOL).  [...]

This is good but too restrictive.  It's analogous to the use of intermediate
languages in optimizing compilers - the language ends up mirroring the source
language and hairifying the backend, or it looks too much like a particular
machine and code for other machines is poor as a result.  An answer is to use
machine description languages, although satisfactory ones for compilers have
yet to appear.  In the environments world, there has been some work on 
interface description languages;  I don't believe any of it is being done
in a Lisp context, however.

>We've been told that the debugger coming in the next Symbolics release
>will be sensitive to the language of the program it is debugging, and
>allow the user to type in expressions in the appropriate syntax.  As
>far as I'm concerned, that's the only part of a debugger that should
>be language-dependent.  Stack tracing, stepping, and breakpoints
>deal with language-independent data structures.

Better, but not there yet.  The structure of the stack is certainly not
language-independent!  The only language-independent stepping I can
think of is at the machine language level, but surely you can't be stepping
by machine instructions in a high-level debugger?  The *concept* of a
breakpoint is independent of language, but certainly the display at a break
in a Prolog is rather different than that for Lisp (at least for those Lisps
which don't have logical variables and choice points :-) ).

>[...] people rarely debug programs using large data sets; when you are
>debugging you create small sample data sets, if only just to speed up
>the debugging cycle.

Of course, if that's possible; if the problem breaks up into little pieces.
That's the easy part of debugging, and I consider it a solved problem.
It's the system integration bugs that are nasty.  You know the sort; all
the parts seem to work perfectly, the bug appears only once in a hundred
runs or only to particular users, and it only appears after the program has
been running for an hour.  Lisp system garbage collectors are a traditional
example - I don't know of any Lisp hackers that would bet large amounts of
money against a tiger team attack on their storage allocator.  A rationale
for Unix-style tools is that one can use them to construct more powerful
debugging tools than those already provided.

>I'm sure that when people debug long pipelines
>they do it by incrementally building up from pairs and triples,
>perhaps sending intermediate output to files so they can examine the
>results.

The pipes I mentioned specifically are *for* debugging; they don't need
debugging themselves!  In fact, a Symbolics-type debugger is completely
useless, because the program (xconq) runs perfectly, but I'm unhappy about
the intelligence of the machine players, and am trying to figure out why.
Small-scale behavior seems to be OK, but is poor on larger examples and
after longer times.

You must not have used pipes very much - the whole point of them is to
*avoid* "sending intermediate output to files". I've used Unix for quite
a while, and my tool usage is far inferior to what real experts do, which
is on a scale that would swamp most Lisps if those tools were in Lisp.  On
the other hand, accommodating Unix tools can involve peculiar restrictions
on the format of data - I believe the ideal is some as-yet-unachieved
combination of tools and integration.  The Lisp community is setting itself
up for a fall by continually calling for more integration, while the rest
of the world is looking for more flexibility... (Of course, I may be
misreading the future, but then that's one of the hazards of academic life!)

>Barry Margolin

							stan shebs
							shebs@cs.utah.edu