Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!teknowledge-vaxc!sri-unix!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.prolog
Subject: Debugging (was Re: Four-Port Debugger)
Message-ID: <467@quintus.UUCP>
Date: 23 Sep 88 03:50:02 GMT
References: <264@quintus.UUCP> <627@ecrcvax.UUCP>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 75

In article <627@ecrcvax.UUCP> micha@ecrcvax.UUCP (Micha Meier) writes:
>In article <264@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>>[example showing the usefulness of REDO ports]
>		- first, when your goal q(~~) succeeds yielding wrong answer,
>		  you normally see it immediately and retry it before
>		  creeping to the next goal
You do _see_ the wrong answer, but that doesn't mean that you _realise_ that
it is wrong.  Much of my debugging involves terms which are so large that
abbreviation is necessary.

>	Before proceeding further, I must say that the idea of a four-port
>	debugger is ingenuous and it is not easy to think about an alternative.
"Ingenuous" = "frank", "naive", "innocent".

For alternatives:
	The DEC-10 Prolog library has a "DEBUG5.PL" which offers a NECK
	port in addition to CALL, EXIT, REDO, and FAIL.

	Dave Plummer has written two debuggers, SODA and CODA.  One of them
	was described at SLP 87.

	Symbolics Prolog has a debugger with lots of stuff in it.

	BIM Prolog has a debugger with lots of stuff in it.  (I find it
	bewilderingly complex, but that's just my personal opinion.)

	The Open University (Milton Keynes, England) is doing a lot of
	work on Prolog debugging.

Then of course there are declarative/rational debuggers...

>	In a clause
>		p :- q, r, s, t.
>	when t/0 fails and the most recent alternative is for q/0,
When t/0 fails, it is not possible for the most recent alternative to
be for q/0.  The most recent alternative can only be for s/0.  If you
want to go back to the first thing with a non-trivial alternative (that
is, the first thing which won't immediately FAIL), that's what the "x"
command is for.

>	   I'd be interested in the experiences of other people
>	with the four-port debuggers, is everybody completely
>	satisfied with them?

No, of course not.  The DEC-10 Prolog debugger is powerful enough to be
useful, and simple enough so that you don't find (re)learning the
debugger to be the hardest part of debugging.  There are lots of other
things which would be nice:
	a way of displaying fewer goals
	automatic checking (of modes or types or whatever)
	automatic loop detection (for debugging only)
	integrated declarative debugging
	do-what-i-meant-not-what-i-said facility
	...

If anyone who described a debugger at the Prolog Environments workshop at
SLP 88 is reading this newsgroup, how about posting a short description
here?  (And of course, anyone working on Prolog debugging who _didn't_
describe the work at SLP 88, please post too.)

There's a lot more to debugging than debuggers.
I have suggested ending one's source files with
	end_of_file.
	
as a method of keeping your code and test harness together (works well
through the Emacs interface).  You can use term_expansion/2 to add
debugging code to predicates, e.g. you might map
	p(T1,...,Tn) :- G1, ..., Gm
to
	p(X1,...,Xn) :- increment(247), X1 = T1,..., Xn = Tn,
			increment(248), G1,
			increment(249), G2, ...
			increment(255).
which would give you "statement counts".  What other debugging techniques
are people using?