Non-termination Analysis of Logic Programs with Integer arithmetics

In the past years, analyzers have been introduced to detect classes of non-terminating queries for definite logic programs. Although these non-termination analyzers have shown to be rather precise, their applicability on real-life Prolog programs is limited because most Prolog programs use non-logical features. As a first step towards the analysis of Prolog programs, this paper presents a non-termination condition for Logic Programs containing integer arithmetics. The analyzer is based on our non-termination analyzer presented at ICLP 2009. The analysis starts from a class of queries and infers a subclass of non-terminating ones. In a first phase, we ignore the outcome (success or failure) of the arithmetic operations, assuming success of all arithmetic calls. In a second phase, we characterize successful arithmetic calls as a constraint problem, the solution of which determines the non-terminating queries.

💡 Research Summary

The paper addresses the problem of automatically detecting non‑terminating queries in Prolog programs that make use of integer arithmetic, a feature that most existing non‑termination analyzers ignore because they are designed for pure definite logic programs. The authors propose a two‑phase analysis that extends their earlier work on mode‑based non‑termination detection (Voets & De Schreye, 2009) to handle built‑in integer constructors (e.g., is/2) and integer comparison predicates (e.g., >=/2, =:=/2).

In the first phase the analysis builds a moded SLD‑tree in which each variable is annotated as either input, output, or integer. Input variables denote arbitrary ground terms, while integer variables denote unknown integer values. The tree is constructed using the standard depth‑first, left‑most Prolog control strategy, and a complete loop‑check (LP‑check) guarantees finiteness. The key idea is to locate a path from a node Nb to a later node Ne that can be repeated indefinitely. Three conditions must hold: (1) no substitutions on input variables occur along the path, (2) the selected atom at Nb is an ancestor of the selected atom at Ne, and (3) the moded more‑general relation holds between the atoms at Nb and Ne. The latter is formalised as “for every concrete instance of the atom at Ne there exists a more‑general instance of the atom at Nb”. Proposition 1 provides a practical unification‑based test for this relation, requiring that any binding introduced by the most general unifier either involves an input variable (which must stay input) or a non‑input variable whose term contains no input variables. If these conditions are satisfied, the path is guaranteed to be applicable to any concrete query represented by the original moded query, regardless of the actual integer values.

However, assuming that all integer comparisons succeed is overly optimistic and would cause many false positives. Therefore, the second phase refines the candidate class of queries by formulating integer constraints that capture the actual success conditions of the integer constructors and comparisons encountered along the candidate path. For example, a condition “M > N” becomes the arithmetic inequality M‑N > 0, and a constructor “M is M0+1” becomes the equation M = M0 + 1. All such constraints are collected and combined into a single constraint system. The system is then handed to a constraint solver (e.g., an SMT solver) after translating integer variables into natural numbers when necessary. If the constraint system is satisfiable, there exists at least one concrete instantiation of the integer variables for which the path can be traversed infinitely; consequently, the original query is truly non‑terminating. If the constraints are unsatisfiable, the path may still exist but will be blocked by a failing integer test, and the query either terminates or fails.

The authors implemented the approach in a prototype analyzer called pTNT, extending their earlier non‑termination tool P2P and the well‑known NTI analyzer. The implementation re‑uses the LP‑check loop detection mechanism and augments the moded SLD‑tree construction with two new transition types: cons for integer constructors and cond for integer conditions. The prototype was evaluated on several benchmark programs that involve integer arithmetic, such as the eq_plus example (which exhibits non‑termination for queries where two arguments are equal) and a deliberately buggy count_to program. In these experiments, the first phase alone identified many potential infinite loops, but the second phase successfully eliminated spurious cases by solving the associated integer constraints. Compared with NTI and earlier versions of their own analyzer, pTNT achieved higher recall for genuine non‑terminating queries while maintaining a low false‑positive rate.

In summary, the paper makes three main contributions: (1) it extends mode‑based non‑termination analysis to handle a realistic subset of Prolog’s built‑in integer arithmetic; (2) it introduces a two‑phase methodology that first over‑approximates possible infinite loops and then refines them using constraint solving, thereby balancing precision and scalability; and (3) it provides a working prototype and empirical evidence that the technique is applicable to real‑world Prolog code. The authors suggest future work on incorporating other non‑logical features such as cuts, floating‑point arithmetic, and on improving the efficiency of the constraint‑solving phase, possibly by tighter integration with modern SMT solvers.