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: Re: The double-cut (The Four-Port Debugger) Message-ID: <264@quintus.UUCP> Date: 9 Aug 88 19:47:06 GMT References: <1162@ttds.UUCP> <208500002@s.cs.uiuc.edu> <227@quintus.UUCP> <609@ecrcvax.UUCP> Sender: news@quintus.UUCP Reply-To: ok@quintus.UUCP (Richard A. O'Keefe) Organization: Quintus Computer Systems, Inc. Lines: 54 In article <609@ecrcvax.UUCP> micha@ecrcvax.UUCP (Micha Meier) writes: >In article <227@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>"Four-port" debuggers are _supposed_ to show "redo"s of built-in predicates. >>... >>Would it be clearer if the "redo" port were renamed to "Next" (short for >>"please give me your next solution"? (C Prolog actually calls this >>port "Back", I think, because the debugger isn't _quite_ a four-port one.) > > I think it would be interesting if people would report about their > experiences with real four-port debuggers - is it really necessary > to show REDO of deterministic calls? Well, Quintus' debugger is a real four-port debugger, if ever there was one. There is an 'x' command (as there was in DEC-10 Prolog) to take you to the next "real" choice-point. I for one am profoundly grateful for the REDO port, not just for the symmetry, but because it gives me a stopping place where I can issue a r)etry command. I would LOATHE having re-execute large chunks of the tree to get back to a particular goal just because someone cleverly decided that because it was determinate I should never be able to get back to it again. What I'm getting at is this: suppose I have a predicate p(~~) :- q(~~), r(~~). and in a particular case q(~~) succeeds, but delivers the wrong answer, so that r(~~) fails. We see something like this: CALL p(~~) c % creep CALL q(~~) s % skip EXIT q(~~) c % creep CALL r(~~) s % skip FAIL r(~~) c % oh dear, creep back to previous goal REDO q(~~) r % retry q ~a message saying that the debugger is going to retry~ CALL q(~~) s % now creep into q Since I take pains to make my code determinate whenever that is appropriate, if the REDO port did not appear on q, I would have lost a large chunk of my tree and would have to spend several painful minutes reconstructing it. r)etry is one of the most powerful features of four-port debuggers. Let's not cripple it, please! > (Btw, are there Prologs around which can trace compiled code? > We'd like to share some experiences on this topic.) How do you mean "trace"? Quintus Prolog can put spypoints on compiled code. If you put a spypoint on each of your predicates, it is pretty much the same as tracing interpreted code. The ALS Prolog debugger operates on compiled code (because there isn't anything else in ALS Prolog). The LOGIX system will trace compiled FCP (if I've understood this correctly, it does so by applying source-to-source transformations). I don't think any of these three systems will let you look at the stack of code that wasn't expecting to be looked at, is that what you had in mind?