Debugging Prolog Programs

Debugging an imperative program usually means stepping through a sequence of assignments to find the line that produced a wrong value. Debugging Prolog means reasoning about unification and backtracking instead: a bug is typically a wrong answer, a missing answer, or an infinite loop, and the cause is usually an unexpected clause ordering, an unintended variable binding, or a search path that never terminates rather than a single faulty statement.

Calling trace/0 activates Prolog's box model debugger, which reports every goal invocation through four ports: Call when a goal is first invoked, Exit when it succeeds, Redo when backtracking re-enters it looking for another solution, and Fail when it fails outright. The leash/1 predicate controls which of these ports actually pause execution for interactive inspection, letting you skip noisy ports like Call while still stopping on Fail.

Tracing an entire program port by port is overwhelming once a program grows past a handful of predicates. spy/1 sets a breakpoint on a specific predicate indicator, such as spy(fact/2), so the tracer only activates when that predicate is called, and nospy/1 removes it again. This lets you isolate suspected predicates without wading through unrelated goals firing elsewhere in the program.

Three patterns account for most Prolog bugs. A singleton variable, one that appears only once in a clause, is almost always a typo, and SWI-Prolog will warn about it at load time. A missing cut lets a predicate that should succeed once backtrack into unwanted alternative solutions on redo. And confusing is/2 with =/2 causes subtle failures: is/2 evaluates its right-hand side as arithmetic and requires it to already be a bound expression, while =/2 merely attempts unification and succeeds on structurally matching terms without evaluating anything.