bob@primerd.UUCP (01/28/87)
# I'm doing some research on debugging techniques, and I'm interested in the special kinds of bugs a Prolog programmer encounters. (There are obviously some things about Prolog which make it unique in this respect.) I'd like to hear about problems people have had, and how they uncovered them. Bug stories are always interesting. I'd also like to hear your opinion about what sort of tools would make Prolog debugging easier. Bob Pellegrino Prime Computer decvax!genrad!mit-eddie!primerd!bobsun!bob (617) 879-2960 x4276
wup@rpics.RPI.EDU (Peter Y.F. Wu) (02/02/87)
In article <445@primerd.uucp>, bob@primerd.uucp writes: > I'd like to hear about problems people have had... Typo is a common mistake. When that happens with the functor name of a predicate, it results in undefined predicates in the Prolog program. It may be nice for a Prolog system to *optionally* flag undefined predicates so that one does not have to trace it all the way to realize it is a typo in the functor name. It has to be optional since undefined predicate may be a deliberate feature to generate failure. Peter Y.F. Wu wup@csv.rpi.edu ...seismo!rpics!wup
bsmith@iuvax.UUCP (02/09/87)
Typo-caused errors in Prolog programs can be hard to find. The errors fall into two classes: (i) in a predicate -- In the head of a clause, this causes the clause to be part of the definition of the wrong (possibly new) procedure. In the body, it causes a call to the wrong (and possibly undefined) procedure. (ii) in a variable -- A typo can either make a variable name the same or not the same as another variable in the clause. In either case, the misspelled variable gets the wrong binding. Typos in punctuation and non-variable terms are easier to catch. At least I seldom have any problems with them. Of course, the reader screams at me if my parentheses or brackets don't match. And, I tend to use longer names for variables and predicates than for atoms or functors. Style rules, as in Quintus Prolog, catch lots of these. In particular, (i) clauses defining a procedure should come together in a file -- A typo in the head of a clause may violate this rule, either by not matching the clauses around it or by matching a clause somewhere else. (ii) the anonymous variable '_' should be used for singleton variables -- A misspelled variable name that makes a non-singleton variable into a singleton variable violates this rule. Of course they don't catch everything. (And, yes, if you're annoyed by them, it is possible to turn them off.)