bimbart@hera.cs.kuleuven.ac.be (Bart Demoen) (06/21/91)
In article <6403@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: > What exactly is it you don't like about the 4-port debugger? it is the slower way to debug also, trying to debug a program you didn't write yourself, is more painful with the 4-port debugger, as compared to a source oriented debugger I am not saying that the 4-port debugger is completely useless, but perhaps nearly so > (There are other models around; the 5-port debugger, AORTA, BIM's one.) forget about 5-port debugging in ProLog by BIM as well: it is still there, but once you use the source oriented debugging tool (which looks very much like dbxtool) you will not want to use the port debugger any more Bart Demoen
brady@swift.cs.tcd.ie (06/22/91)
What don't I like about the four port debugger. Well, I can't think of anything better, yet, but the thing is that it's, well, procedural. The names have been changed to protect the innocent, but there it is. Anyhow, I keep hoping for something neater. I didn't mean to imply 4-port and source code are mutually exclusive, just that Open Prolog doesn't provide source-code debugging. Maybe we can discuss this in Paris? Over some light refreshment? Mike
mcovingt@athena.cs.uga.edu (Michael A. Covington) (06/22/91)
In article <1991Jun21.220758.7981@swift.cs.tcd.ie> brady@swift.cs.tcd.ie writes: >What don't I like about the four port debugger. >Well, I can't think of anything better, yet, but the thing >is that it's, well, procedural. Precisely! Prolog implements *procedures* for proving theorems, and one cannot use Prolog effectively without knowing the procedures that the computer will execute. Prolog is no more a non-procedural language than Fortran. (Fortran a non-procedural language? Of course! Its big selling point, back in 1958, was that it let you write A=B+C instead of LOAD B, ADD C, STORE A.) -- ------------------------------------------------------- Michael A. Covington | Artificial Intelligence Programs The University of Georgia | Athens, GA 30602 U.S.A. -------------------------------------------------------
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/24/91)
In article <4055@n-kulcs.cs.kuleuven.ac.be>, bimbart@hera.cs.kuleuven.ac.be (Bart Demoen) writes: > In article <6403@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au > (Richard A. O'Keefe) writes: > > > What exactly is it you don't like about the 4-port debugger? > > it is the slower way to debug > also, trying to debug a program you didn't write yourself, is more painful with > the 4-port debugger, as compared to a source oriented debugger > I am not saying that the 4-port debugger is completely useless, but perhaps > nearly so There is an utterly false distinction being drawn here between the four-port debugger and a source debugger. What makes a four-port debugger a four-port debugger is WHERE IT CAN STOP, where you can set breakpoints. What makes a debugger a source debugger is WHAT IT CAN DISPLAY. The two questions are completely independent. For example, the Prolog system you can get from Edinburgh (was "NIP", now "Edinburgh Prolog") is a 4-port source debugger. Similarly, the debugger that came with IF/Prolog right from the beginning was a 4-port source debugger. > forget about 5-port debugging in ProLog by BIM as well: it is still there, > but once you use the source oriented debugging tool (which looks very much > like dbxtool) you will not want to use the port debugger any more So does the NIP debugger look a lot like dbxtool. That has *NOTHING* to do with whether it is a four-port debugger or not. It would be fair, for example, to describe dbxtool as a 2-port source debugger for C. -- I agree with Jim Giles about many of the deficiencies of present UNIX.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/24/91)
In article <1991Jun21.220758.7981@swift.cs.tcd.ie>, brady@swift.cs.tcd.ie writes: > What don't I like about the four port debugger. > Well, I can't think of anything better, yet, but the thing > is that it's, well, procedural. I don't see how the four-port debugger is particularly procedural. It is a tool for walking around the proof tree. Ok, you don't have unrestricted access to the tree (though Dave Bowen wrote a debugger at Edinburgh that showed you a lot more of the tree). But how does that make it procedural? Ok, so what about Shapiro's Declarative Debugging (revised as Rational debugging, or whatever)? What about the DEC-10/Quintus Prolog "advice package" which lets you check claims such as "every well formed call to this predicate has such-and-such a property"? > Maybe we can discuss this in Paris? Over some light refreshment? Wish I could be there. -- I agree with Jim Giles about many of the deficiencies of present UNIX.