Debugging Logic Programs Using Specifications

Logic programming has gained in popularity" in recent years. This style of programming, using Horn clauses to express procedural information, allows one to reason easily about the effects of executing program statements. We present a methodology for reasoning about the relationship between logic programs and their specifications, to help debug erronneous programs. To Mlow for debugging, the specifications must describe the relationships between the values of input and output variables. Since Horn clauses are a powerful subset of firstorder logic, a program's specifications can oftentimes be written in Prolog itself and executed by the Prolog interpreter or compiler directly. (Whereas specifications are intended to emphasize clarity and simplicity, in implementing programs, efficiency is a major consideration.) The debugger follows the pattern of Shapiro's ([12]). We focus on the use of executable specifications to generate test cases for bug discovery, locate bugs when test data cause a program to fail, and guide deductive and inductive bug correction ([3]). We also ask that specifications provide information on the well-founded ordering of input arguments for recursive procedures. (A well-founded ordering ~is a transitive and irreflexive binary relation on elements of a set S such that the S has no infinite descending sequences.) The ordering specifies, for each recursive call, which arguments should be decreasing. This is used for detecting looping. Programs, for our purposes, are presumed to obey their Horn clause declarative semantics, i.e., extra-logical features, such as cuts, clause order, and subgoM order, may affect efficiency and termination, but not correctness. We also presume that specifications faithfully reflect the intended requirements of a program. To obtain the desired effect, it is sometimes necessary to use impure features, i.e., non-logical control structures, of Prolog.