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?