1 Introduction
For many definite programs there exist queries for which the SLDtree (under the lefttoright computation rule) is infinite. In some cases the infinite tree contains no solution. This paper is about proving the latter efficiently. Our original motivation stems from the world of planning. Typically, a planner searches an infinite space of candidate plans for a plan satisfying all requirements. It is useful to have a second process which searches for a proof that not all requirements can be met; if found, the first process can be stopped (and the other way around if a plan is found). Another application is in proving that a program satisfies certain integrity constraints. For example, a program defining even and odd numbers should satisfy the integrity constraint that no number is both even and odd. This can be proven by showing that the query
even(X), odd(X) fails.Failure of a query Q can be proven by showing that Q is not a logical consequence of the program, in other words by constructing an interpretation in which the program clauses are true (i.e. which is a model of the program) and in which Q is false (or alternatively, the clause false Q is true). First order model generators [27, 28, 35, 24] can be used for this task. They search for an interpretation over a finite domain such that all clauses of a given set evaluate to true.
This paper develops an alternative approach which exploits the fact that definite programs have least models. If Q is false in some model based on a preinterpretation, then it is also false in the least model based on that preinterpretation. Hence, it should be better to search in the space of preinterpretations for a preinterpretation such that Q is false in the least model based on it than to search in the larger space of interpretations for an interpretation such that the program clauses are true and Q is false.
While this paper is one of the first to address the problem of proving that an SLDtree contains no solutions, the related problem, proving that the SLDtree is finite, has received a lot of attention in the literature on termination analysis. See [13] for a survey. As argued above, useful programs exist for which the SLDtree is not finite.
The problems caused by infinite branches in proof trees have also been addressed in work on loop checking [2, 3, 26]. The idea is to monitor the execution and to try to prune infinitely failing branches. However, methods have to choose between pruning too much (causing incompleteness of the proof procedure) and preserving completeness but missing some infinite branches. Proof procedures with tabling such as XSB [25] are perhaps a better alternative to a completeness preserving procedure equipped with loop checking. They avoid the overhead of monitoring the execution while using a different proof procedure which, compared to SLD, reduces the number of infinite branches. In particular, they always terminate for DATALOG programs.
The work in [4] takes a different approach. A logic program is represented as a set of equivalence preserving rewrite rules. One of the effects of the “simplification inference rule” is to eliminate certain infinite derivations. We have not studied this approach in detail. We suspect its power is comparable to that of conjunctive partial deduction [22, 14] which is discussed in Section 5.
Section 2 recalls the basics about preinterpretations and introduces a trivial example. Section 3, explains how a preinterpretation can be described by a number of facts, how a program can be abstracted as a DATALOG program, and how the least model based on that preinterpretation can be queried by evaluating the abstracted query on the DATALOG program. Section 4 develops two procedures for proving failure. The first one combines abduction with tabulation and failure analysis. The second one combines constraints with tabulation and develops two alternatives for the constraint solving. The first alternative uses abduction and failure analysis in the constraint checking. The second one translates the constraints into finite domain constraints and uses a finite domain solver for the constraint checking. Section 5 discusses alternative approaches: the use of model generators for first order logic [27, 28, 35, 24], of type analysis [19, 10] (a query fails if its inferred type is empty) and of program specialisation [22, 14] (the query fails if the program —for the given query— can be specialised into the empty program). In section 6, the different approaches are compared. Finally, in section 7, we draw some conclusions. We assume some familiarity with the basics of tabulation, e.g. [31, 25, 33].
2 Preliminaries
A preinterpretation of a program consists of a domain and, for every functor a mapping from to . An interpretation based on a preinterpretation extends with a mapping from to for every predicate in . Extending the language of the program with the domain , an interpretation can be identified with the set of atoms for which is mapped to .
An interpretation is a model of a program iff all clauses of are true under the interpretation . For every preinterpretation , a definite program has a model based on (map to for all predicates and all domain elements). The intersection of a set of models based on is also a model based on , hence there is a unique least model based on . We denote this model by . As a consequence, if an existentially quantified conjunction (a query) is false in a model based on a preinterpretation then it is also false in . So, to check whether some preinterpretation can be the basis of a model in which an existentially quantified conjunction is false, it suffices to evaluate the conjunction in . This can be summarised in the following proposition:
Proposition 1
Given a preinterpretation , there exists an interpretation I based on which is a model of {false Q} iff false Q.
Example 1
Even/odd
even(0)
even(s(X)) odd(X).
odd(s(X)) even(X).
, ,
The least model is . The query
even(X), odd(X) fails because is false in this model. Executing the program with SLD or
with a tabulating procedure (e.g. XSB [25])
results in infinite failure. All methods discussed in Section
5 can handle this problem.
A variable assignment is a mapping from variables to domain elements. Given a preinterpretation , this mapping can be extended in a term assignment (variables are assigned according to , functors according to ). denotes the term assignment of under the preinterpretation and variable assignment . Given an interpretation , the mapping can be further extended to a truth assignment. gives the truth value of the formula under the interpretation (based on a preinterpretation ) and the variable assignment .
3 Proof procedures
In [12], Codish and Demoen developed so called abstract compilation to perform groundness analysis of logic programs. Applying a transformation on the original program, they obtain an abstracted program. Groundness is then derived from a least model of the abstracted program. In later work [11], they used the same technique to perform other analyses. Boulanger and coauthors [7, 6] explored the use of preinterpretations to approximate the ssemantics [5] of programs and to derive properties from this approximation. In [18], the approach of Codish and Demoen is generalised and presented as defining a preinterpretation and computing the least model of the abstracted program; several applications are presented. It became clear that abstract compilation is a technique allowing the efficient computation of a program’s least model based on a preinterpretation.
Abstract compilation consists of eliminating non variable terms from clauses. A term f(t1,…,tn) is replaced by a fresh variable X and a call p(t1,…,tn,X) is added to the body of the clause. This is repeated until all non variable terms have disappeared from the program clauses. Note that this transformation is independent from the particular preinterpretation. The abstract program is completed with the preinterpretation in relational form: the set of facts {p(d,…,d,d) }. Each fact represents a component of the preinterpretation. With a preinterpretation, denotes its relational form.
Example 2
Applying abstract compilation on the program and preinterpretation
of Example 1, we obtain:
even(X) p(X)
even(Y) p(X,Y), odd(X).
odd(Y) p(X,Y), even(X).
p()
p(,)
p(,)
The clauses together with the facts of the preinterpretation
form a DATALOG program. The least model is . The
formula is false in this model. While
the query even(X), odd(X) is nonterminating under
SLD, it fails finitely under well known proof procedures such as
bottomup evaluation after magicset transformation or topdown
methods enriched with tabulation such as OLDT [31] and XSB
[25].
In what follows, we give some results formalising the relationship between a program and its abstraction. First, we introduce some notational conventions. With a clause, denotes its abstraction; with a set of clauses (a program), denotes its abstraction. is the Herbrand preinterpretation of . Remark that has the same domain as as the domain elements are the only functors in . denotes the interpretation which is the least Herbrand model of . Finally, is the interpretation of corresponding to the interpretation when .
Theorem 3.1
Let be an interpretation of based on preinterpretation
and the corresponding interpretation of . The
interpretation is a model of {false
Q} iff is
a model of {false Q}.
Proof.
Consider a slightly different clause transformation which replaces a term f(t1,…,tn) by a fresh variable X and adds the equality f(t1,…,tn) = X to the body of the clause. Repeat this transformation until all non variable terms are eliminated from argument positions in program predicates and from argument positions in terms of the equalities. The difference between the resulting clause and the abstracted clause is that has an equality f(X1,…,Xn) = X where has a call p(X1,…,Xn,X).
This new transformation is equivalency preserving hence iff .
Given a variable assignment , is true iff . We also have that is true iff . Hence, . Also for program predicates, we have , hence iff . As this holds for all clauses and for the query, the theorem follows. ∎
Abstract compilation is a simple variant of more general transformation to substitute predicate symbols by function symbols which is well known in logic, e.g. [17].
Corollary 1
Given a sound and complete proof procedure, the query Q fails for the program iff there
exists an interpretation based on such that is
false.
Proof
By Prop. 1, is false iff
false Q.
By Theorem 3.1, false
Q iff false Q.
is the least Herbrand model of ,
hence, given a sound and complete proof procedure,
Q fails iff false
Q iff is false. ∎
4 The search for the right preinterpretation
To prove failure, the approach is to select a domain and a preinterpretation and to show finite failure when executing the abstracted query with the abstracted program. A straightforward way consists of selecting a domain and trying all preinterpretations until one is found for which the query fails. If none exists, one can try again with a larger domain. However, for programs with a substantial number of function symbols and constants, this quickly results in a very large search space. Indeed, with a element domain, an ary functor has possible preinterpretations.
Hence better is to consider , the part defining the preinterpretation, as unknown and the use a procedure which can guess the missing predicate definitions. Abduction [21] is such a mechanism. In an abductive setting, given is a logic program defining a subset of its predicates, a set of integrity constraints in classical logic and some query . Abduction searches a definition of the open, abducible predicates, i.e. those not defined by such that and . For our problem, the defined predicates are those defined by (the set of abstracted clauses), the abducibles are , the query is the abstracted query not Q (we want a solution for which the query fails) and the integrity constraints are axioms restricting to correspond to a preinterpretation which is a total function, i.e. . Hence the problem is to find a such that false Q and satisfies the integrity constraints.
In a first experiment, we have used the general purpose abductive procedure SLDNFA [16] to solve the problem. A first problem that we met was that SLDNFA looped on the abstract program due to nonacyclic recursion in it. To overcome this problem, the clauses defining the recursive predicates were transformed into integrity constraints. Some initial experiments showed the feasibility, but also the need for a dedicated procedure which allows to experiment with different control strategies.
Abduction is complex in the general case due to the presence of variables in abductive calls and the interaction with negation as failure. We are only concerned with definite programs, that simplifies substantially the design of a dedicated procedure. Moreover, we know that the preinterpretation of a functor is a total function from to . Hence, a complete preinterpretation has exactly one fact p(d1,…,dn,d) for every tuple of domain elements and is also a domain element. As a consequence, our abductive procedure has only to “guess” among the domain elements for the value of . So it becomes fairly simple to ensure correctness and completeness. A call p(t1,…,tn,t) needs to be resolved with all the facts p(d1,…,dn,d) such that unifies with . If some of these facts do not yet exist, they have to be abduced. To obtain an exhaustive search over all candidate abductive solutions, one has only to take care that all domain elements are in turn considered as candidate values for .
To overcome the problem of looping, our dedicated procedure makes use of tabulation. Tabulation [31, 25, 33] avoids non termination in the case of DATALOG programs. As we only consider definite programs, the concept is fairly simple. When a call p(t1,…,tn) to a tabled predicate is selected in a goal, the goal is suspended and the query p(t1,…,tn) is evaluated in isolation of its goal. Eventually, evaluation of this new query leads to computed answer substitutions . For each of these answers , an answer lemma p(t1,…,tn) is stored (if not the renaming of a previous answer) in the table associated with the call p(t1,…,tn). The suspended goal is reactivated for each answer lemma and a resolution step is performed, using the answer lemma as program clause. If in another goal the atom p(s1,…,sn) is selected and the atom happens to be a renaming of p(t1,…,tn), then no separate query for p(s1,…,sn) is launched. The goal is simply suspended and is reactivated for each answer lemma stored in the table associated with the query p(t1,…,tn).
As the abstract program has no functors apart from the 0arity domain elements, only a finite number of distinct calls can occur. Also, for each call, only a finite number of distinct answers can occur, hence termination is ensured.
We prefer topdown evaluation with tabulation above bottomup evaluation because topdown is goal directed. Our procedures use heuristics; these try to find those refutations which are short and use as few different components of the preinterpretation as possible first. We find it more convenient to design such heuristics in the context of a topdown procedure.
As a final remark, it is well possible that not all components of a preinterpretation are needed to evaluate a particular abstract query. In such case, our dedicated procedure will not abduce the complete preinterpretation. For the not abduced facts p(d1,…,dn,d), any value can be chosen. Adding them will neither modify the proof structure nor the outcome of the query evaluation.
4.1 An abductive approach
When experimenting with a dedicated abductive procedure, an early observation concerned the tabulation mechanism. Typically, several table entries were created for the same predicate. Frequently, a “final” call occurred with a call pattern where all arguments are free variables. This final call subsumed all previous ones. Hence it is more efficient, when a call p(t1,…,tn) occurs to a tabled predicate, to compute once and for all the answers to the most general query p(X1,…,Xn). Unification of the call p(t1,…,tn) with the answer lemmas then selects the answers to the call which occurred. We also observed that it was preferable to table all program predicates, whether recursive or not. Again the sum of the costs of evaluating each separate call was larger than evaluating once the most general call. We adopted these strategies in all our systematic experiments and it is hard wired in the description of the procedure below.
We need some notational conventions to describe the procedure. The state of the computation is represented as a set of clauses. The symbol Cl represents a clause and the symbol Cls represents a set of clauses. Clauses that are a renaming of each other are considered equal. As and Bs represent sequences of atoms. A clause is represented as H As in which the head H is an atom (or false). s and t ( and
) denote a term (a vector of terms);
d () denotes a domain element (a vector of domain elements).The procedure (Fig. 1) is described as a set of inference rules which extend the state with new clauses. Given a query As, the initial state of the derivation is represented as {false As}. p/n refers to a predicate of the original program; calls to such predicates are tabled. The tabulation has an implicit representation: a predicate is tabled when the clauses defining it occur in the state; answer lemmas for p/n occur in the state as facts p() (when all calls in the body of a clause defining p/n are solved, a fact is left). abduce() is the notation we use for a call to an abducible predicate p() of the preinterpretation. These calls are not tabled. A clause H Lookup(p()),As is a suspended clause, waiting for answers of the call p(). For simplicity of representation we assume the computation rule always select the leftmost atom in the body of a clause.
Nr  State  Condition  New State 

1a  {H p(),As}  not_tabled(p)  {H Lookup(p()),As} 
Cls  {Cl Cl is a clause defining p}  
Cls  
1b  {H p(),As}  tabled(p)  {H Lookup(p()),As} 
Cls  Cls  
2  Cls which contains  unify(,)  {(H As)mgu(,)} 
p() and  Cls  
H Lookup(p()),As  
3  Cls which contains  unify(,)  {(H As)mgu(,)} 
abduce() and  Cls  
H abduce(),As  
4  Cls which contains  : (unify(,) and d:  {abduce(,)} Cls 
H abduce(,),As  abduce(,) Cls)  where is a domain element  
5  Cls  false Cls  failure 
We assume a fixed number of domain elements. Rules 1 to 3 describe the execution under tabling. Given a complete preinterpretation, these rules will derive all consequences. Rule 1 handles a call to a tabled predicate. The clauses defining it are added to the state when it is the first call to the predicate (1a). Whether the first call or not, the clause is suspended (the selected call is wrapped inside Lookup). Rule 2 uses an answer lemma to derive a new clause from a suspended one and rule 3 uses a fact from the preinterpretation to derive a new clause (here and elsewhere, the necessary renaming is omitted to simplify the presentation). Rule 4 performs abduction on demand: if rule 3 needs a component of the preinterpretation which is not yet defined, then rule 4 adds such a component to the state. The value assigned to the component is chosen from the domain. This rule is nondeterministic; it derives one new state for each domain element. Rule 5 detects that the query has a solution, i.e. that the (partial) preinterpretation being considered does not meet the requirement. Hence it replaces the state by the final state failure.
A solution is found when a final state is reached that is different from failure, (no new clauses can be derived). Although the preinterpretation can still be partial, any extension to a complete preinterpretation is the basis for a model of the program in which the query fails.
Correctness and termination.
Assuming the preinterpretation (the set of facts abduce()) is complete, rules 2 and 3 perform unit resolution on a set of clauses consisting of the query and the program clauses. Rule 1 is a heuristic which delays resolution steps on program clauses until it is certain they can contribute in the derivation of the empty clause from the query. Unit resolution is known to be a correct and complete proof procedure for definite clauses; moreover, as the Herbrand universe of the program is the finite domain of the preinterpretation, only a finite number of clauses can be derived and termination is ensured (for a fixed preinterpretation).
However, the computation start with an empty preinterpretation. The role of rule 4 is to create a component of the preinterpretation as soon as rule 3 can make use of it. This does not affect correctness. As rule 4 can only choose among a finite number of domain elements, and can only be applied a finite number of times in a particular derivation, overall termination remains ensured. Rule 5 plays the role of a filter, it stops the derivation when it detects that the query has a solution.
Control.
In our implementation, the choice offered by rule 4 is implemented through enumeration and backtracking. When applying rule 4, a choice point is created which keeps track of the untried domain elements. When rule 5 is activated, it triggers backtracking to the last choice point where the next value is tried. If none, backtracking continues to the previous choice point. The overall computation fails as soon as backtracking occurs and no alternative is left in any choice point.
The order in which rules are applied can have a big impact on the size of the search space. Obviously, rule 5, which triggers backtracking should be activated as soon as a clause (false) is inferred. Also, the creation of a new choice point should be delayed as long as possible, i.e. one should not create another choice point if the already abduced facts allow to infer the clause (false). A simple implementation almost realising this strategy selects the leftmost literal in a clause body and applies the applicable rule, delaying the processing of the clause if the selected literal is an abducible for which not all instances are already abduced. Once no other rules are applicable, rule 4 is applied on one of the delayed clauses. Experiments showed that more complex strategies —causing more metainterpretation overhead— which do not necessarily select the leftmost literal tend to perform better. In processing new clauses, the system reported in section 6 has a preference for applying a lookup step (rule 2). If none is applicable it attempts to apply rule 3 on an abducible literal for which all matching components of the preinterpretation are defined (so that all resolvents can be computed at once and the original clause can be removed). If the clause has no such abducible, it is delayed. Once all clauses are delayed, it gives preference to the application of rule 1 on a clause with only calls to program predicates. If no such clause is delayed, rule 4 is applied on a delayed clause. A heuristic selects the delayed clause containing the abducible which needs the least number of yet to be abduced instances to allow for the application of rule 3 and abduces those instances.
4.2 A constraint approach
We use a more compact notation in this section. We write abduce(f(a),X) instead of abduce(Y), abduce(Y,X) With this notation, the abstraction of an atom p(f(a)) becomes abduce(f(a),X), p(X).
A weakness of the abductive approach can be illustrated with the following example: assume that the preinterpretation of a functor f/1 has already been abduced as abduce(f(d1),d1) and abduce(f(d2),d2) and that a clause false abduce(f(g(h(a))),X), abduce(g(h(a)),X) is derived. The preinterpretation of f/1 is such that for all domain elements , , hence, whatever the preinterpretation for a/0, h/1, and g/1, false will be derived. The abductive system will abduce preinterpretations for a/0, h/1, and g/1, and will then discover the failure. It will exhaustively enumerate all preinterpretations for a/0, h/1, and g/1 before backtracking to the preinterpretation of f/1.
A constraint based approach can to a large extent avoid such problems. We consider the abducibles as constraints and use a special purpose constraint solver which checks the existence of a preinterpretation which satisfies all constraints. In the above example, if the preinterpretation of f/1 is constrained to the shown one and the clause false abduce(f(g(h(a))),X), abduce(g(h(a)),X) is derived, then the solver detects the inconsistency and triggers backtracking.
This approach makes it necessary to reformulate our abductive system. The major difference is with respect to the tabulation. The answers to a tabled predicate are no more simple facts but constrained facts (of the form p() abduce(…), …, abduce(…)). A problem is that one can have an infinite number of syntactically different answers. However, with a finite domain and a fixed preinterpretation, the set of answers (its model) is finite. So it must be possible to add constraints which enforce the finiteness. Before presenting the formal system, we illustrate the main ideas with the even/odd example.
Example 3
Even/odd
The program is as follows:
even(X) abduce(0,X).
even(Y) abduce(s(X),Y), odd(X).
odd(Y) abduce(s(X),Y), even(X).
The execution is shown in Fig. 2. We represent the state of the derivation by three components, the set of clauses, the set of answers and the constraint store which holds the set of constraints (as before, the component with the fixed abstract program is left out). stands for the empty set. Lookup is abbreviated as L, and false, abduce, even and odd respectively as f, ab, e and o. Finally, sb is the abbreviation of subsumed.
 0.

In the initial state the only clause is the query. The leftmost atom is selected; the two clauses defining even/1 are added to the set of clauses and the original clause suspends, waiting for answers from even/1.
 1.

The second clause, a constrained fact, is selected. A choice point is created. The first alternative adds the constraint subsumed(even(X) abduce(0,X),) to the constraint store in an attempt to have the new fact subsumed by the existing ones. Whatever the preinterpretation, abduce(0,d) is true for some domain element and even(d) is an answer which is not subsumed by previous answers as there are none. Hence the constraint is false and the second and last alternative is taken: the fact is added to the set of answers and the constraint not(subsumed(even(X) abduce(0,X),)) is added to the store. The constraint is equivalent to true, hence the store remains empty.
 2.

The call odd(X) is selected in the second clause; the clause defining odd/1 is added. In the (omitted) new state, this clause is chosen and its atom even(X) is selected. As even/1 has been called before, no new clauses are added.
 4.

This step and the next one perform resolution between the answer and suspended first and last clause. In one of the new clauses, abduce(s(X),Y), abduce(0,X) is abbreviated as abduce(s(0),Y).
 6.

One step selects the atom odd(X) in the second clause and suspends the clause. Another step selects the last clause which is a constrained answer. We have a choice point; as there are no previous answers for odd/1, the subsumption constraint leads again to an inconsistent store and the notsubsumption constraint is again equivalent to true. Hence, the net effect is that the clause is added to the answers.
 8.

The next two steps perform resolution between the new answer and the second and third clause, resulting in two new clauses.
 10.

The third clause is a constraint, consistent with the store, and is added to it. The constraint says that 0 and s(0) have to be different under the preinterpretation.
 11.

The fourth clause is an answer for even/1. A choice point is created. The first alternative creates the constraint that the new answer is subsumed by the existing answers: subsumed(even(Y) abduce(s(s(0)),Y), {even(X) abduce(0,X)}). It is consistent with the constraint store (e.g. with , subsumed(even(), {even()}) is true), hence it is added to it and the answer clause is dropped. The new constraint says that and have to be equal under the preinterpretation.
 12.

No new clauses can be derived. The store is consistent, hence there exists a preinterpretation satisfying it (e.g. abduce(0,d1), abduce(s(d1),d2) and abduce(s(d2),d1)) and even(X), odd(X) is false in the least model based on a preinterpretation consistent with the constraint store.
The inference rules of the constraint procedure are shown in Fig. 3. A state, consisting of clauses, answers and a constraint store is represented as Cls Answ Store. The symbols As and Bs stand for any sequence of atoms, while Abds stands for a sequence consisting solely of abduce atoms. Store stands for a conjunction (set) of constraints, Answ for a set of answers (constrained facts) and Answ for the subset of answers about predicate p . The initial state is given by false As where As is the query. subs() is an abbreviation for subsumed() and not_subs() for not(subsumed()); inconst() is an abbreviation for inconsistent(). Remember that arguments of program predicates of the abstracted program are always variables.
Nr  State  Condition  New State 
1a 
{H p(),As} Cls  not_tabled(p)  {H Lookup(p()),As} Cls 
Answ Store  {Cl Cl is a clause defining p}  
Answ Store  
1b 
{H p(),As} Cls  tabled(p)  {H Lookup(p()),As} Cls 
Answ Store  Answ Store  
2 
Cls Answ Store  unify(,)  {(H Abds, As)mgu(,)} Cls 
p() Abds Answ  Answ Store  
H Lookup(p()),As Cls  
3 
{false Abds} Cls  Cls Answ  
Answ Store  {false Abds} Store  
4 
Cls Answ Store  inconst(Store)  failure 
5a 
{p() Abds} Cls  Cls Answ  
Answ Store  {subs(p() Abds,Answ)}  
Store  
5b 
{p() Abds} Cls  Cls {p() Abds} Answ  
Answ Store  {not_subs(p() Abds,Answ)}  
Store 
Rules 1a, 1b and 2 are as before. Rule 3 adds a new constraint to the constraint store. Rule 4 stops the derivation with failure when the store is inconsistent. Rule 5 processes a new answer lemma. It is a non deterministic rule. 5a handles the alternative where it is enforced that the new answer lemma is subsumed by the existing answers (Answ). The lemma is deleted and the subsumption constraint is added to the store. 5b handles the case where it is enforced that the answer is not subsumed by the previous one. It is added to the answers and the negation of the subsumption constraint is added to the store.
Correctness and termination.
This proof procedure preserves the properties about correctness and completeness of the abductive one. In terms of the inferences it makes, the difference is that it uses constrained facts {p() Abds} instead of facts p() and that it delegates the processing of the calls to the abducibles to the constraint solver. Hence the inferences it makes are correct and completeness is preserved. Termination remains ensured if the number of answers for each program predicate remains finite and consistency checking is terminating. A not(subsumed(…)) constraint stating that the new answer is not subsumed by the previous ones is added to the constraint store each time that a new answer is added to the answer set. With the size of the domain, the number of distinct atoms in the model of a ary predicate is limited to . Hence, if more than answers are added for the same predicate, an inconsistent store will be reached. The consistency check has to verify that a preinterpretation exists which satisfies all constraints. As the number of different preinterpretations is finite and the number of constraints is finite, its termination can be ensured.
Control and consistency checking.
The best way to handle the choice offered by rule 5 is through enumeration and backtracking where preference is given to rule 5a as it leads to the smallest answer set, hence to the shortest derivation.
In the abductive algorithm the choice implies a commitment for a particular component of the preinterpretation. In this algorithm the choice does not imply such a direct commitment. However, adding a non redundant constraint reduces the number of preinterpretations that satisfy all constraints; it is a kind of indirect commitment.
The solver which has to verify the consistency plays a crucial role. We have explored two alternatives. The first approach (abductive solver) abduces the components of the preinterpretation as needed during the verification of the constraints. Backtracking is triggered when a constraint is violated. (This is similar to the strategy in the abductive algorithm, but at the level of the constraint checking.) Note that the constraint checking can be incremental; each time a new constraint is added, the search starts from the partial preinterpretation satisfying all previous constraints.
The second approach (finite domain solver) encodes the search for a preinterpretation as a finite domain problem. A finite domain variable ranging over the domain of the preinterpretation is associated with the terms occurring in the constraints and boolean variables are used to express the equality between the preinterpretation of different terms. We sketch the encoding using the evenodd example. Let be the domain of the preinterpretation. A finite domain variable ranging over represents the preinterpretation of a term and boolean variables indicates whether or not the terms and have the same preinterpretation. Such boolean variables are linked to the domain variables through definitions which ensure propagation of new information. Consider the constraint false abduce(0,X), abduce(s(0),X). To handle it we introduce finite domain variables and . We can translate the constraint to false = X, = X or, after elimination of X: false or . To express the connection between and , we add for all the constraint ^{1}^{1}1Or equivalently .. Note that this implies the creation of finite domain variables . Now consider the constraint subsumed(even(Y) abduce(s(s(0)),Y),{even(X) abduce(0,X),}). It contains a new term , so a domain variable is created and it is linked with by adding for all the constraint . The subsumption constraint is expressed as . (Its negation is represented as .) This translation ensures that all choices which are made are immediately propagated.
4.3 Failure analysis and symmetries
Consider the abductive system and the constraint system with the abductive solver. Chronological backtracking is triggered by the derivation of a false clause. However, not all the components of the preinterpretation abduced so far necessarily have contributed to its derivation. So, chronological backtracking may result in thrashing. The amount of backtracking can be substantially reduced. In the context of the abductive system, a simple approach is to associate with each clause the set of abductive facts used in its derivation. In each derivation step, the set associated with the new clause is the union of the sets of the two parent clauses. When abducing a new fact, the associated set is the abduced fact itself. In this way, when false is derived, one obtains an associated conflict set identifying the abduced facts used in the derivation of the clause. Backtracking is then directed to the last abduced fact in the set. To support also the derivation of secondary conflict sets, the technique of intelligent backtracking [8] is used. With a conflict set which backtracks to the generator of , the conflict set is stored with the generator of this abductive component. If it happens that all possible assignments for that component get rejected, then one obtains a set of conflicts which can be formalised as: . Applying hyperresolution on these clauses and , which expresses that there must be a domain element assigned to the term , one obtains the secondary conflict and one can backtrack to the most recent abducible in that set. Note that a tradeoff between the time lost in rediscovering the same conflict set and the time and space lost in storing and checking previous conflict sets has to be made. It is done by storing the conflict set with the generator of the most recent abduced fact present in the conflict set. This approach avoids inefficiencies in accessing relevant conflict sets. However, if, due to another conflict, one backtracks beyond that generator, then the information about the conflicts stored with it is lost. Notwithstanding that this conflict set still can have potential use for future pruning.
The conflict sets obtained in this way are not optimal. In fact, as Peltier [24] points out, it is not feasible to compute optimal conflict sets: if there is no model for the given domain size, the optimal conflict set is empty. However further improvements are feasible. For example, consider the clause false t1 = t2, Y = t3. It leads to the clause false whenever the preinterpretations of t1 and t2 are equal. However, our approach will also include the components used in computing the preinterpretation of t3. Improved failure analysis could be achieved by applying substitutions. Indeed for any expression E, the (pre) interpretation of for which does not occur in is equal to the (pre) interpretation of . The abductive constraint solver uses this rule to simplify false Abds constraints. The abductive procedure does not use it as it performs abstract compilation as a preprocessing step and the integration of this optimisation would require a complete redesign of the system (one should keep track of the used components of the preinterpretation at the level of individual terms instead of at the clause level). The abductive constraint solver also sharpens the conflict set of violated subsumption constraints: it selects an argument for which the subsumption constraint is violated and returns as conflict set the components used in evaluating that argument.
As noted by Peltier [24], applying a permutation of the domain on a partial (pre) interpretation yields an isomorphic (pre) interpretation. It can be extended into a model iff the original one can be extended in a model. In particular, if is a conflict set, so is with a permutation of . There is again a tradeoff between the time lost in rediscovering an isomorphic conflict and in storing and using such conflicts to prune the search. We follow what we understand to be the approach in [24]: when a conflict set is found and the system backtracks and considers the next candidate, it is checked whether that candidate has a subset which is isomorphic to the conflict set which triggered the backtracking. For example, assume a conflict is derived and the enumeration modifies the second component in . The new partial preinterpretation contains the set which is isomorphic to the original one under the permutation and is rejected. Note that is also isomorphic to the original conflict set. While it can be part of a candidate still to be explored in the search space, this conflict set is not stored for future pruning.
5 Alternative approaches
Model generation.
The logic program and the clause false query can be considered as a logical theory. A model of this theory is a proof that the query fails. There exist general purpose tools for generating models of logical theories. FINDER [27, 28], written in C, is such a tool; it takes as input a set of clauses in a manysorted first order language, together with specifications of finite cardinalities of the domains for the sorts, and generates interpretations on the given domains which satisfy all the clauses [27]. A basic difference with our approach is that it not only enumerates the preinterpretation but also the interpretation (the mapping from the atoms to true or false). Also, it is not goal directed; the system checks whether all ground instances of all clauses are true in the candidate interpretation. If a clause instance is found which is false, then the components of the interpretation which have been used in the evaluation make up what we called the conflict set and are used to direct the search (using hyperresolution as described in Section 4.3 to derive secondary conflicts). Another difference is that FINDER stores conflict sets permanently (unless they are too big) and uses elaborate algorithms to exploit them efficiently in pruning the search. FINDER reports a model when it discovers an interpretation which is true for all clause instances. FINDER uses a typed language and can only handle binary predicates and functors. To overcome that restriction we used a special encoding for predicates and functors of higher arity. For example, with the size of domain and a ternary functor, we introduce a domain with cardinality , a binary functor , and a binary functor . Then we replace every occurrence by . In addition should have a different value for each different input and FINDER should not backtrack over the choices made for . This can be achieved with declaring injective and ensuring that the choice points for are created first. [28] states that the order in which functors are declared is important and that the first declared ones change least rapidly during the backtracking. The first results we obtained with FINDER [9] were rather poor. The results reported in the current paper are much better. They are obtained with the ordering which places the special functor first, then the constants, then the other functors and finally the predicates.
In a recent paper, Peltier [24] presents a new system FMC which claims to do a better failure analysis than FINDER and SEM [35], and exploits symmetries to further improve the pruning of the search space. As with other finite model builders for first order logic, it enumerates the full interpretation, not only the preinterpretation. Our understanding is that the concept of covering refutation used to prune the search is very similar to our use of intelligent backtracking (which we added to our system described in [9] after we learned about the work of Peltier).
Regular approximations.
Within the context of program analysis, the most obvious approach to prove failure is to add a clause shouldfail() query() and to use one or another kind of type inference to show that the successset of shouldfail() is empty. A typical representative of such systems is described in [19]; it computes a regular approximation of the program. Roughly speaking, for each argument of each predicate, the values it can take in the successset^{2}^{2}2The set of ground atoms which are logical consequences of the program. are approximated by a type (a canonical unary logic program). Failure of the query is proven if the types of shouldfail() are empty. Also set based analysis [20] can be used to approximate the successset. Setbased analysis originates from [23]; it was then studied (improved and implemented) in [20]. The tool that we use is a composition of inference of a directional type (as in [10], based on setbased analysis) with the theorem prover SPASS [34].
Program specialisation.
One could also employ program transformation, and more specifically program specialisation techniques to prove failure of the query. If for the given query, the program can be specialised in the empty program, then the query trivially fails. A technique which has almost the same power as transformations based on the fold/unfold approach is conjunctive partial deduction [22, 14]. By specialising conjunctions of atoms instead of single atoms, it can achieve substantially better results than other specialisers. For example it can specialise the even/odd program into the empty program for our example query.
6 Experiments
Table 1 gives details about the benchmarks^{3}^{3}3The code is available at http://www.cs.kuleuven.ac.be/~henkv/pre. Besides the name, the table gives the number of clauses (without the query), the number of predicates, the size of the domain, the size of a preinterpretation, the number of different preinterpretations (including symmetric ones), the size of an interpretation (the number of atoms to be mapped to true or false), and the number of different interpretations (for a fixed preinterpretation).
name  #clauses  #pred  size(dom)  size(pre)  #pre  size(int)  #int/pre 

odd_even  3  2  2  3  4  
wicked_oe  4  3  2  10  10  
appendlast  4  2  3  12  13  
reverselast  4  2  3  12  13  
nreverselast  6  3  5  28  150  
schedule  12  6  3  12  24  
multiseto  7  1  2  7  4  
multisetl  4  2  2  7  12  
blockpair2o  15  3  2  19  12  
blockpair3o  15  3  2  36  20  
blockpair2l  14  5  2  19  32  
blockpair3l  14  5  2  36  40  
blocksol  14  5  2  19  32  
BOO0191  4  1  3  32  9  1 
odd_even is a trivial example about even and odd numbers. wicked_oe is an extension which adds a call to each clause and 4 functors which are irrelevant for success or failure. It allows us to see whether failure analysis is accurate enough to achieve the same level of pruning as in odd_even. appendlast, reverselast, nreverselast and schedule are small but hard examples. On one hand, they illustrate the use of integrity constraints to express program properties; on the other hand, they have circulated as challenging problems for program specialisers which should be able to specialise them into the empty program. The query for appendlast expresses the integrity constraint that appending a list ending in a cannot result in a list ending in a b. The query for reverselast expresses that reversing a list with the accumulating parameter initialised as [a] cannot result in a list ending in a b. The query for nreverselast expresses naive reverse applied on a list beginning with an a cannot result in a list ending in a b. Finally, the schedule program is a program that attempts to transpose successive positions in a list of elements until a configuration is reached with two successive c elements. The query expresses the integrity constraint that such configuration cannot be reached from a configuration consisting of one c followed by one or more n. multiseto and multisetl are programs to check the equivalence of two multisets. While the first uses a binary operator “o” to build sets, the second uses a list representation and auxiliary predicates to manipulate the list. The others are typical examples from a large set of planning problems reasoning on multisets of resources. The first two use the “o” representation for the multiset, the next two the “l” (list) representation. blockpair2o and blockpair2l omit the for success or failure irrelevant argument for collecting the plan (and have 6 functors less). blocksol is there to show what happens when the query does not fail. It uses the list representation and also omits the argument collecting the plan. Finally, BOO0191 is an axiomatisation of a ternary boolean algebra, a typical problem from the theorem proving community taken from the TPTP library [29]). Its only predicate is equality, whose interpretation can be fixed to the identity (so the number of different interpretations is only 1 instead of ).
The abductive system AB uses the control as described in Section 4.1 and is augmented with the intelligent backtracking and symmetry checking as described in Section 4.3. The constraint system gives lowest priority to rule 5 which create a choice point. Rule 4 which checks for consistency of the constraints is activated each time a new constraint is generated. The system with the abductive solver (ABCS) also uses intelligent backtracking and is able to derive more accurate conflict sets than AB. The system with the finite domain solver (FDCS) does not apply intelligent backtracking as this is difficult to integrate with the standard pruning techniques of finite domain solvers [32]. Both constraint systems eliminate only the most obvious symmetry in the search space (when starting the enumeration with abduce(X) they will consider only one domain value for X).
The abductive systems are implemented in Prolog. The queries have been executed with MasterProlog on a SUN sparc Ultra2. The constraint system FDCS is also written in Prolog, uses the SICSTUS finite domain solver and was running under SICSTUS Prolog [30] on the same machine. ABCS was also running under SICSTUS Prolog. FINDER is implemented in C and was also running on a SUN sparc Ultra2. Regular approximations (RA) were computed with a system due to John Gallagher, conjunctive partial deduction (CPD) with a system due to Michael Leuschel. Witold Charatonik was so kind to run our examples on his tool for set based analysis (SBA) described in Section 5. Finally, Nicolas Peltier was so kind to run our examples on the FMC system [24] under a SUN4 ELC.
Table 2 gives the times for the various systems. The times are in seconds, unless followed by H, in which case it is in hours. The notation H means no solution was found after hours; M means out of memory. For CPD, RA and SBA, we do not give times as these systems do not perform an exhaustive search but a standard analysis of the given program. yes means failure was proven. As blocksol does not fail, it was not run on these systems.
Table 3 gives the number of backtracks. For the constraint systems, two numbers are given, #bckt is the number of backtracks inside the solver, i.e. those with respect to the preinterpretation, #Tbckt is the number with respect to the choices made regarding tabling.
name  AB  FDCS  ABCS  FINDER  FMC  CPD  RA  SBA 

odd_even 
0.01  0.00  0.00  0.02  0.00  yes  yes  yes 
wicked_oe  0.07  0.00  0.00  0.02  0.01  yes  yes  yes 
appendlast  0.53  0.45  0.09  0.17  45.21  yes  no  yes 
reverselast  0.38  3.70  0.94  0.17  10.79  no  no  yes 
nreverselast  5.87H  19H  19H  16.5H  900  yes  no  no 
schedule  0.10  0.31  0.07  0.03  0.15  no  no  yes 
multiseto  0.04  0.04  0.02  0.02  0.02  no  yes  yes 
multisetl  0.01  0.06  0.03  0.02  0.08  yes  no  yes 
blockpair2o  1.83  0.38  0.11  0.08  7.31  no  no  no 
blockpair3o  7.60  0.42  0.14  0.18  900  no  no  no 
blockpair2l  2.83  2.36  1.17  0.05  204.9  no  no  no 
blockpair3l  29.24  2.49  1.34  0.12  M  no  no  no 
blocksol  200.78  7.7H  2558.58  1896.3  900       
BOO0191  1.20  4.34  0.14  0.03  0.06  no  no  no 
name  AB  FDCS  ABCS  FINDER  FMC  

#bcktr  #bcktr  #Tbcktr  #bcktr  #Tbcktr  #bcktr  #bcktr  
odd_even  4  0  0  0  0  1  3 
wicked_oe  64  0  0  0  0  8  52 
appendlast  43  24  1  55  1  618  110019 
reverselast  30  68  2  303  2  614  23445 
nreverselast  190170  ?  ?  ?  ?  ?  
schedule  24  13  1  106  1  37  497 
multiseto  10  7  0  30  0  0  104 
multisetl  3  6  1  21  1  12  469 
blockpair2o  17  25  0  49  0  262  5567 
blockpair3o  56  25  0  51  0  879  ? 
blockpair2l  28  3943  2  2733  2  68  91404 
blockpair3l  130  4009  2  2737  2  366  ? 
blocksol  3615  1396146  385  1970544  169  4007523  ? 
BOO0191  72  4  0  34  0  14  33 
6.1 Discussion
One should refrain from comparing results for individual examples. A different order over the choice points can give a very different result. This is definitely so for FINDER, which imposes an almost static ordering over the choice points. The order used in [9] was giving much worse results. The abductive system AB determines the order dynamically. Still, a small change in the heuristics for selecting the next rule application can result in a different order over the choice points and in substantially different results. For example, a variant of the AB system solved blockpair3l in 2.60s with 18 backtracks (but was doing worse when considering the whole benchmark suite).
The effects of pruning based on symmetries in the AB system is not reported in the tables. Of the problems with 2 element domains, it triggers only one pruning step in blocksol which has to search the whole solution space. It causes one pruning step in each of the problems with 3 element domains, but makes the difference on nreverselast where a 5 element domain is needed to construct a model. There, it causes 120 pruning steps in the search space of the AB system.
Comparing the twin problems odd_even and wicked_oe, blockpair2o and blockpair3o, blockpair2l and blockpair3l, we observe that FDCS with the finite domain solver is almost not distracted by the (for the failure) irrelevant extra functors. Apparently, its control strategy is such that those extra functors are enumerated as the last ones, when the more constrained functors already received a correct assignment in the domain of the preinterpretation. Also the failure analysis of the abductive solver ABCS turns out to be very accurate and the amount of backtracking is almost unaffected by the extra functors. The failure analysis of the abductive system AB includes those functors in conflict sets so that the backtracking becomes less accurate and more backtracks occur before a solution is found. This also holds for the model generators FINDER and FMC.
The abductive system AB is the only system solving all problems and is doing very well in terms of number of backtracks (apart from wicked_oe and BOO0191). Its implementation is very straightforward (linear lists for clauses, abduced facts and tabled answers), so there is a lot of room for improving its speed. As a consequence it is often slower than the constraint systems. The latter, also implemented in Prolog, use more elaborate data structures.
Both constraint systems FDCS and ABCS are doing pretty well. Although they are also implemented in Prolog, they use more elaborate data structures and are often faster than AB, even when they need more backtracks. Their performance degrades when they have to backtrack frequently over their decision with respect to the subsumption of new answers (#Tbcktr). This is a major weakness. The more they have to backtrack over the subsumption decisions, the more the size of their search space becomes close to that of the model generators FINDER and FMC. A problem is that they have no control over the order of these choice points and cannot do better than chronological backtracking over all possibilities. This problem is prominent in blocksol where they have to search the whole space of interpretations of size whereas AB searches in the space of preinterpretations of size . The poor performance in this problem is not a real drawback. The use of the model generator should be combined with the use of a theorem prover which should be able to find a plan for blocksol. We suspect this problem is at the basis of their failure on the nreverselast problem where the domain size is 5. A positive point is that answer lemmas can contain variables, in which case they cover several ground answers. This limits somewhat the number of different answer sets which have to be considered during the search. (FINDER needs much more backtracks on the blocksol problem.)
Whereas our original results [9] confirmed those of [24] that FMC most of the time outperforms FINDER, more fine tuning of the FINDER input reversed the picture. Its implementation in C and its use of specialised data structures pays of on the class of problems we consider. It is fast on all but the hard problems. In blocksol it is beaten by AB (over 4 million backtracks against 3615 for AB) and it was stopped on nreverselast after 50 million backtracks. FINDER is preprocessing short clauses. Likely this eliminates a lot of candidate solutions (it solves multiseto without backtracking). FMC, which has no such preprocessing, is unable to solve several problems, in particular the planning problems with a list representation. The latter problems are those where the the reduction of search space by our approach (the space of preinterpretations versus the space of interpretations —see last column in Table 1—) is largest.
The advantage for our systems that they search the smaller space of preinterpretations disappears on the TPTP problem BOO0191 and similar problems. Hence the first order model generators do as well or better in terms of number of backtracks and, due to their fine tuned C implementations, outperform our systems in speed.
Conjunctive partial deduction can handle some of the problems which are difficult for us, but cannot handle any of the planning problems. Computing regular approximations is fast, but it can show failure of the most simple problems only. The set based analyser is more precise and fails only on the planning problems, nreverselast and BOO0191.
7 Conclusion
For definite logic programs, we have addressed the problem of proving that certain queries cannot succeed with an answer. A problem which is particularly relevant when the query does not fail finitely. We have developed two new approaches which aim at searching a model of the program in which the query is false. We have performed some experiments using (rather small) example programs and queries which do not terminate^{4}^{4}4These programs also loop when using tabulation or when executing bottomup after a magic set transformation.. We also did a comparison with other approaches which could be used to tackle this problem: general purpose model generation tools, the use of type inference, and the use of program specialisation. In the case of type inference, the approach is in fact also to compute a model. However, the chosen model is the one which best reflects the type structure of the program. If the query happens to be false in this model, then failure is shown. Also in the case of program specialisation, showing failure is a byproduct of the approach: for some queries, the program happens to be specialised into the empty program.
Abduction is a very powerful and general problem solving technique. It was pretty easy to formulate the problem of searching a preinterpretation such that the query is false in the least model based on it as an abductive problem and to use a general purpose abductive procedure[16]. But we quickly realised that we had almost no control over the search for a solution. Our first approach was to built a special purpose abductive procedure for definite programs which employs tabulation and which hard wired the constraints that preinterpretation of functors are total functions. The idea behind the proof procedure is to use a topdown evaluation strategy —abducing a part of the preinterpretation only when needed in evaluating the query— and to prevent looping by the use of tabulation. Experiments confirmed our intuition that it was important to delay the abduction of new components in the preinterpretation as long as possible (to propagate all consequences of what was already abduced to check whether it was part of a feasible solution). After adding failure analysis to improve upon chronological backtracking as in systems as FMC [24] and FINDER [27, 28], the system is doing quite well. It outperforms FMC in speed and number of backtracks. Compared with FINDER, it typically needs much less backtracks, though it can only beat FINDER in speed for a couple of hard problems.
We also explored a variant which treats the definition of the preinterpretation as constraints. This allows to delay the decisions up to the point were answers had to be tabled: at such a point one needs to know whether the answer is new or not. Still we do not fix the preinterpretation at such a point but formulate constraints on the preinterpretation, using a solver to check the existence of a preinterpretation satisfying all constraints. We experimented with a finite domain solver and with an abductive solver. We obtained good results; however the systems start to slow down when a lot of backtracking over the decisions with respect to new answers being subsumed by the existing ones is needed. The number of possible backtracks quickly goes up with the arity of the predicates, as the example blocksol, where the query does not fail, illustrates. It also increases quickly with the size of the domain needed to show failure e.g. nreverselast. Unless one finds some heuristics to control the order of choice points, or some knowledge to do better than the chronological backtracking over these choice points, the abductive system seems more promising.
Our experiments indicate that our approach is a better basis for proving failure of queries over definite programs than applying general purpose model generators such as FINDER and FMC. Searching the space of preinterpretations for a preinterpretation such that the query is false in the least model based on it requires on average much less backtracking than searching the larger space of interpretations. Searching in the smaller space of preinterpretations has a cost: the query needs to be evaluated in the least model. Tabulation turned out to be a very effective approach which keeps the cost of the query evaluation at acceptable levels. (As the program abstracted under the preinterpretation is a DATALOG program, also loop checking can ensure termination of the query evaluation. At some point we experimented with this and got a very large slow down as the number of derived clauses substantially increased.)
Our approach is also more powerful than type inference based on Regular Approximations. Conjunctive Partial Deduction and Set Based Analysis turn out to be quite powerful on some classes of problems but cannot solve any of the planning problems.
A limitation of our approach, but also of the model generators is that they cannot prove failure if the query is only false in a model based on an infinite domain. For example less(N,s(N)) and less(N,s(M)) less(N,M) and the query less(N,M),less(M,N). Also set based analysis and conjunctive partial deduction are unable to prove failure of this query.
In a broader context, this paper makes contributions to the following topics:

A (first) study of methods to prove (infinite) failure of definite logic programs.

The development of a proof procedure which combines tabulation with abduction and of a constraint based procedure which treats the abducibles as constraints and uses a constraint solver to check the existence of a solution for the abducibles. Also the latter procedure uses tabulation.

A better understanding of the power and limitations of abduction. While very expressive, our findings suggest that abductive procedures need to be augmented with “background” knowledge to direct the search for abductive solutions. Simply specifying the properties of an abductive solution as an integrity constraint cannot provide sufficient guidance to the search for a solution. It is interesting to observe that background knowledge is also often the key to success in Inductive Logic Programming which makes use of inductive procedures which are in more than one aspect “twins” of abductive procedures [1].

The further development of model based program analysis. [18] showed that model based program analysis implicitly introduced in [12] is also an excellent method for type inference. In [18] it was shown that there exist preinterpretations which encode various other declarative properties of programs. Our work takes this work one step further by developing methods for automatically constructing a preinterpretation which expresses a particular program property (or integrity constraint) expressed as a query which should fail.
Acknowledgements
The author are grateful to the reviewers for the detailed comments and the many suggestions for improvement. M. Bruynooghe is supported by FWOFlanders. This research was supported by the EC (a grant from the HCM project ERBCHBGCT9303365 to D.A. de Waal), by the INTAS project 931702 Efficient Symbolic Computing, by the GOA projects NonStandard Application of Abstract Interpretation and LP+: a Second Generation Logic Programming Language and by the FWO projects Linguaduct and Knowledge Representation and Computation in Open Logic Programming.
References

[1]
H. Ade and M. Denecker.
Abductive inductive logic programming.
In C.S. Mellish, editor,
Proc. of the International Joint Conference on Artificial Intelligence
, pages 201–1209. Morgan Kaufman, 1995.  [2] K.R. Apt, R.N. Bol, and J.W. Klop. On the safe termination of Prolog programs. In Proc. ICLP’89, pages 353–368, Lisbon, June 1989. MIT Press.
 [3] R.N. Bol, K.R. Apt, and J.W. Klop. An analysis of loop checking mechanisms for logic programs. Theoretical Computer Science, 86(1):35–79, August 1991.
 [4] M.P. Bonacina and J. Hsiang. On rewrite programs: semantics and relationship with Prolog. Journal of Logic Programming, 14(1&2):155–180, October 1992.
 [5] A. Bossi, M. Gabbrielli, G. Levi, and M. Martelli. The ssemantics approach: Theory and applications. J. Logic Programming, 19/20:149–197, 1994.
 [6] D. Boulanger and M. Bruynooghe. A systematic construction of abstract domains. In Proceedings SAS’94 (Static Analysis Symposium), LNCS 864, pages 61–77. SpringerVerlag, 1994.
 [7] D. Boulanger, M. Bruynooghe, and M. Denecker. Abstracting ssemantincs using a modeltheoretic approach. In Proceedings PLILP’94 (Programming Language Implementation and Logic programming), LNCS 844, pages 432–446. SpringerVerlag, 1994.
 [8] M. Bruynooghe. Solving combinatorial search problems by intelligent backtracking. Information Processing Letters, 12(1):36–39, 1981.
 [9] M. Bruynooghe, H. Vandecasteele, D.A. de Waal, and M. Denecker. Detecting unsolvable queries for definite logic programs. In Principles of Declarative Programming, Proc. PLILP’98, ALP’98, LNCS 1490, pages 118–133. SpringerVerlag, 1998.
 [10] W. Charatonik and A. Podelski. Directional type inference for logic programs. In Giorgio Levi, editor, Proceedings of the Fifth International Static Analysis Symposium (SAS), LNCS 1503, pages 278–294, Pisa, Italy, 1998. SpringerVerlag.
 [11] M. Codish and B. Demoen. Deriving polymorphic type dependencies for logic programs using multiple incarnations of prop. In Proceedings SAS’94 (Static Analysis Symposium), LNCS 864, pages 281–296. SpringerVerlag, 1994.
 [12] M. Codish and B. Demoen. Analysing logic programs using “prop”ositional logic programs and a magic wand. Journal of Logic Programming, 25(3):249–274, December 1995. First version in ILPS’93.
 [13] D. De Schreye and S. Decorte. Termination of logic programs: the neverending story. Journal of Logic Programming, 19 & 20:199–260, May/July 1994.
 [14] D. De Schreye, R. Glück, J. Jørgensen, M. Leuschel, B. Martens, and M.H. Sørensen. Conjuctive partial deduction: foundations, control, algorithms and experiments. J. Logic Programming, 1999. To appear.

[15]
D.A. de Waal, M. Denecker, M. Bruynooghe, and M. Thielscher.
The generation of preinterpretations for detecting unsolvable
planning problems.
In U. Furbach, editor,
Proc. IJCAI Workshop on Model based Automated reasoning
, pages 103–112, 1997.  [16] M. Denecker and D. De Schreye. SLDNFA: an abductive procedure for abductive logic programs. Journal of Logic Programming, 34(2):201–226, Februari 1998.
 [17] H. B. Enderton. A Mathematical Introduction To Logic. Academic Press, 1972.
 [18] J. Gallagher, D. Boulanger, and H. Saǧlam. Practical modelbased static analysis for definite logic programs. In J. Lloyd, editor, Proc. ILPS’95, pages 351–365, Portland, Oregon, December 1995. MIT Press.
 [19] J.P. Gallagher and D.A. de Waal. Fast and precise regular approximations of logic programs,. In P. Van Hentenryck, editor, Proc. ICLP94, pages 599–613. MIT Press, 1994.
 [20] N. Heintze. Set based program analysis. PhD thesis, School of Computer Science, Carnegie Mellon University, 1992.
 [21] A.C. Kakas, R.A. Kowalski, and F. Toni. Abductive logic programming. J. Logic and Computation, 2(6):719–770, 1992.
 [22] M. Leuschel, D. De Schreye, and D.A. de Waal. A conceptual embedding of folding into partial deduction: Towards a maximal integration. In Michael Maher, editor, Proceedings of the Joint International Conference and Symposium on Logic Programming JICSLP’96, pages 319–332, Bonn, Germany, September 1996. MIT Press.
 [23] P. Mishra. Towards a theory of types in Prolog. In IEEE International Symposium on Logic Programming, pages 289–298, 1984.
 [24] N. Peltier. A new method for automated finite model building exploiting failures and symmetries. J. Logic and Computation, 8(4):511–543, 1998.
 [25] K. Sagonas, T. Swift, and D.S. Warren. XSB as an efficient deductive database engine. In Proceedings of SIGMOD 1994 Conf. ACM. Acm Press, 1994.
 [26] Y.D. Shen. An extended variant of atoms loop check for positive logic programs. New Generation Computing, 15(2):187–203, 1997.
 [27] J. Slaney. FINDER: Finite domain enumerator system description. Technical Report TRARP294, Centre for Information Science Research, Australian National University, Australia, 1994. Also in Proc. CADE12.
 [28] J. Slaney. FINDER  finite domain enumerator  version 3.0  notes and guide. Technical report, Centre for Information Science Research, Australian National University, Australia, 1997.
 [29] C.B. Suttner and G. Sutcliffe. The TPTP problem library, version 2.1.0, 15/12/1997. Technical Report 97/08, James Cook University, Australia, 1997.
 [30] Swedish Institute of Computer Science. SICSTUS Prolog User’s Manual, November 1997.
 [31] H. Tamaki and T. Sato. OLD resolution with tabulation. In Ehud Shapiro, editor, Proceedings ICLP’86, Lecture Notes in Computer Science, pages 84–98, London, 1986. SpringerVerlag.
 [32] P. Van Hentenryck. Constraint Satisfaction in Logic Programming. The MIT press, 1989.
 [33] D.S. Warren. Memoing for Logic Programs. Communications of the ACM, 35(3):93–111, March 1992.
 [34] C. Weidenbach. SPASS version 0.49. Journal of Automated Reasoning, 18(2):247–252, 1997.
 [35] J. Zhang and H. Zhang. SEM: a system for enumerating models. In Proc. IJCAI95, Vol. 1, pages 298–303. Morgan Kaufmann, 1995.
Appendix
7.1 Prolog code of examples
odd_even.
Here and further on, the considered queries are the bodies of 0arity predicates.
even(zero). even(s(X)) : odd(X). odd(s(X)) : even(X). odd_even : even(X), even(s(X)).
wicked_oe.
A version of odd_even with an extra superfluous argument which creates a term with 4 different functors.
wicked_even(zero,U) : wicked_p(U). wicked_even(s(X),U) : wicked_odd(X,_V), wicked_p(U). wicked_odd(s(X),U) : wicked_even(X,_V), wicked_p(U). wicked_p(f(g(h(a)))). wicked_oe : wicked_even(X, _U1), wicked_even(s(X),_U2).
appendlast.
Appending to a list cannot yield a list ending in a .
app([],L,L). app([HX],Y,[HZ]) : app(X,Y,Z). last([X],X). last([H,H2T],X) : last([H2T],X). appendlast: app(X, [a], Xs), last(Xs, b).
reverselast.
If the accumulator is initialised with a list ending in , then the result of the call to reverse cannot be a list ending in a .
last([X],X). last([H,H2T],X) : last([H2T],X). reva([], Acc, Acc). reva([YZ], R, Acc): reva(Z, R, [YAcc]). reverselast: reva(L, R, [a]), last(R, b).
nreverselast.
Reversing a list beginning with an cannot result in a list ending in .
rev([], []). rev([XY], R): rev(Y, S), app(S, [X], R). app([],L,L). app([HX],Y,[HZ]) : app(X,Y,Z). last([X],X). last([H,H2T],X) : last([H2T],X). nreverselast : rev([aX], R), last(R, b).
schedule.
There cannot be 2 ’s in a list with all ’s but the first element.
mv(R): tr(R,NewR), mv(NewR). mv(R): atleast2c(R). % success iff R is nonsafe state tr([c,nRs], [n,cRs]). tr([nRs], [nNewRs]): tr(Rs,NewRs). tr([],[]). cFirst([cQs]): nOnly(Qs). nOnly([nQs]): nOnly(Qs). nOnly([n]). atleast2c([cL]): atleast1c(L). atleast2c([nL]): atleast2c(L). atleast1c([c_]). atleast1c([nL]): atleast1c(L). schedule: cFirst(R), mv(R).
multiseto.
A program to check that two multisets contain the same elements. The multiset is represented with a functor o/2 and a constant emptyMultiSet. This is more a specification than a program. It needs iterative deepening to find answers.
sameMultiSet(X, X). sameMultiSet(o(X, Y), o(X, Z)) : sameMultiSet(Y,Z). sameMultiSet(o(o(X, Y), Z), U) : sameMultiSet(o(X, o(Y, Z)), U). sameMultiSet(U, o(o(X, Y), Z)) : sameMultiSet(U, o(X, o(Y, Z))). sameMultiSet(o(emptyMultiSet, X), Y) : sameMultiSet(X, Y). sameMultiSet(X, o(emptyMultiSet, Y)) : sameMultiSet(X, Y). sameMultiSet(o(X, Y), Z) : sameMultiSet(o(Y, X), Z). multiseto : sameMultiSet(o(a,o(a,emptyMultiSet)), o(_X,o(emptyMultiSet,b))).
multisetl.
The same problem as a normal Prolog program using lists. The query ml1 corresponds to the query m1. It does not terminate due to the presence of the variable.
sml([], []). sml([XY], D) : delete(X, D, E), sml(Y, E). delete(M,[MT], T). delete(M, [HT], [HL]) : delete(M, T, L). multisetl : sml([a], X), sml(X, [b]).
blockpair2o.
A number of planning problems based on a planner due to Michael Thielsher which operates on a multiset of resources. It has to be executed under iterative deepening to find plans for most problems (which have a solution).
In the first problem, the argument collecting the plan —which is irrelevant for the existence of a solution— is omitted. The multisets are represented using a constant for the empty set and a binary operator.
causesPair(I1, I2): sameMultiSet(I1, I2). causesPair(I, G): actionPair(C, E), sameMultiSet(o(C, Z), I), causesPair(o(E, Z), G). actionPair(ho(V), o(ta(V),o(cl(V),em))). actionPair(o(cl(V),o(ta(V),em)), ho(V)). actionPair(o(ho(V),cl(W)), o(on(V,W),o(cl(V),em))). actionPair(o(cl(V),o(on(V,W),em)), o(ho(V),cl(W))). actionPair(o(on(V,W),o(cl(V),em)), o(on(s(s(V)),s(V)), o(on(s(V),V), o(on(V,W), o(cl(s(s(V))),em))))). actionPair(o(on(s(s(V)),s(V)), o(on(s(V),V), o(on(V,W), o(cl(s(s(V))),em)))), o(on(V,W), o(cl(V),em))). sameMultiSet(X, X). sameMultiSet(o(X, Y), o(X, Z)): sameMultiSet(Y, Z). sameMultiSet(o(o(X, Y), Z), U): sameMultiSet(o(X, o(Y, Z)), U). sameMultiSet(U, o(o(X, Y), Z)): sameMultiSet(U, o(X, o(Y, Z))). sameMultiSet(o(emptyMultiSet, X), Y): sameMultiSet(X, Y). sameMultiSet(X, o(emptyMultiSet, Y)): sameMultiSet(X, Y). sameMultiSet(o(X, Y), Z): sameMultiSet(o(Y, X), Z). blockpair2o: causesPair(o(on(s(nul),nul), o(ta(nul), o(cl(s(nul)),em))), o(on(s(s(nul)),s(nul)), o(on(s(nul),nul), o(ta(nul), o(cl(s(s(nul))),em))))).
blockpair3o.
Same problem but with the extra argument to collect the plan.
causesPair(I1, void, I2): sameMultiSet(I1, I2). causesPair(I, plan(A, P), G): actionPair(C, A, E), sameMultiSet(o(C, Z), I), causesPair(o(E, Z), P, G). actionPair(ho(V),put_down(V),o(ta(V),o(cl(V),em))). actionPair(o(cl(V),o(ta(V),em)),pick_up(V),ho(V)). actionPair(o(ho(V),cl(W)),stack(V,W),o(on(V,W),o(cl(V),em))). actionPair(o(cl(V),o(on(V,W),em)),unstack(V),o(ho(V),cl(W))). actionPair(o(on(V,W),o(cl(V),em)),add_two, o(on(s(s(V)),s(V)), o(on(s(V),V), o(on(V,W), o(cl(s(s(V))),em))))). actionPair(o(on(s(s(V)),s(V)), o(on(s(V),V), o(on(V,W), o(cl(s(s(V))),em)))), delete_two, o(on(V,W), o(cl(V),em))). sameMultiSet(X, X). sameMultiSet(o(X, Y), o(X, Z)): sameMultiSet(Y, Z). sameMultiSet(o(o(X, Y), Z), U): sameMultiSet(o(X, o(Y, Z)), U). sameMultiSet(U, o(o(X, Y), Z)): sameMultiSet(U, o(X, o(Y, Z))). sameMultiSet(o(emptyMultiSet, X), Y): sameMultiSet(X, Y). sameMultiSet(X, o(emptyMultiSet, Y)): sameMultiSet(X, Y). sameMultiSet(o(X, Y), Z): sameMultiSet(o(Y, X), Z). blockpair3o: causesPair(o(on(s(nul),nul), o(ta(nul), o(cl(s(nul)),em))), _Plan, o(on(s(s(nul)),s(nul)),o(on(s(nul),nul),o(ta(nul), o(cl(s(s(nul))),em))))).
blockpair2l.
The next planner represents resources as a list. No argument to collect the plan.
causesPairl(I,I). causesPairl(I,G) : actionPairl(C,E), m_subset(C,I,Z), app(E,Z,S), causesPairl(S,G). actionPairl([ho(V)],[ta(V),cl(V),em]). actionPairl([cl(V),ta(V),em], [ho(V)]). actionPairl([ho(V),cl(W)], [on(V,W),cl(V),em]). actionPairl([cl(V),on(V,W),em], [ho(V),cl(W)]). actionPairl([on(V,W),cl(V),em], [on(s(s(V)),s(V)),on(s(V),V),on(V,W),cl(s(s(V))),em]). actionPairl([on(s(s(V)),s(V)),on(s(V),V),on(V,W),cl(s(s(V))),em], [on(V,W),cl(V),em]). m_subset([], L, L). m_subset([HT], L1, L2): delete(H, L1, L3), m_subset(T, L3, L2). delete(M, [MT], T). delete(M, [HT], [HL]): delete(M, T, L). app([], X, X). app([XY], Z, [XW]): app(Y, Z, W). blockpair2l : causesPairl([on(s(0),0),ta(0),cl(s(0)),em], Sequence), m_subset([on(s(s(0)),s(0)),on(s(0),0),ta(0), cl(s(s(0))),em], Sequence, []).
blockpair3l.
With an extra argument to collect the plan.
causesPairl(I,void,I). causesPairl(I,plan(A,P),G) : actionPairl(C,A,E), m_subset(C,I,Z), app(E,Z,S), causesPairl(S,P,G). actionPairl([ho(V)],put_down(V),[ta(V),cl(V),em]). actionPairl([cl(V),ta(V),em],pick_up(V),[ho(V)]). actionPairl([ho(V),cl(W)],stack(V,W),[on(V,W),cl(V),em]). actionPairl([cl(V),on(V,W),em],unstack(V),[ho(V),cl(W)]). actionPairl([on(V,W),cl(V),em],add_two, [on(s(s(V)),s(V)),on(s(V),V),on(V,W),cl(s(s(V))),em]). actionPairl([on(s(s(V)),s(V)),on(s(V),V),on(V,W),cl(s(s(V))),em], delete_two, [on(V,W),cl(V),em]). m_subset([], L, L). m_subset([HT], L1, L2): delete(H, L1, L3), m_subset(T, L3, L2). delete(M, [MT], T). delete(M, [HT], [HL]): delete(M, T, L). app([], X, X). app([XY], Z, [XW]): app(Y, Z, W). blockpairl: causesPairl([on(s(nul),nul),ta(nul),cl(s(nul)),em], _Plan, Sequence), m_subset([on(s(s(nul)),s(nul)),on(s(nul),nul), ta(nul),cl(s(s(nul))),em], Sequence, []).
blocksol.
Finally a case where there exists a solution.
actionZerol([ho(V)], [ta(V), cl(V), em]). actionZerol([cl(V), ta(V),em], [ho(V)]). actionZerol([ho(V), cl(W)], [on(V,W), cl(V), em]). actionZerol([cl(V), on(V, W), em], [ho(V), cl(W)]). actionZerol([on(X, Y), cl(X), em], [on(s(X), X), on(X, Y), cl(s(X)),em]). causesZerol(I, I). causesZerol(I, G) : actionZerol(C, E), m_subset(C,I, Z), app(E, Z, S), causesZerol(S, G). m_subset([], L, L). m_subset([HT], L1, L2): delete(H, L1, L3), m_subset(T, L3, L2). delete(M, [MT], T). delete(M, [HT], [HL]): delete(M, T, L). app([], X, X). app([XY], Z, [XW]): app(Y, Z, W). blocksol : causesZerol([on(s(0),0),ta(0),cl(s(0)),em], [on(s(s(0)),s(0)),on(s(0),0),ta(0),cl(s(s(0))),em]).
7.2 An example of input for FINDER
FINDER supports only nulladic, monadic and dyadic functions. As predicates are declared as functions with boolean as value sort, these restrictions also apply to predicate definitions and forces some transformation for predicates with arity : for example a ternary atom is encoded as where is a binary functor used to encode atoms with predicate p/3 and which constructs a term in a sort different from the sort of the terms , and of the original atom. To have the same expressivity as the original p based on a 2 element domain preinterpretation, the preinterpretation of has to be based on a 4 element domain.
Input for the multisetl problem. The ternary predicate delete/3 has been converted in a binary delete_was3/2 predicate. Besides the sort term for all terms of the original program, a sort pair has been introduced. The extra functor delete_argpair is used to bundle two terms of sort term into one of sort pair.
sort { term cardinality = 2. pair cardinality = 4. } const {a: term. b: term. nil: term. ml1: bool. } function { cons: term, term > term. delete_argpair: term, term > pair. delete_was3: term, pair > bool. sml: term, term > bool. } clause {ml1 > false. sml(cons(a, nil), z), sml(z, cons(b, nil)) > ml1. sml(nil, nil). delete_was3(y, delete_argpair(w, z)), sml(x, z) > sml(cons(y, x), w). delete_was3(z, delete_argpair(cons(z, y), y)). delete_was3(w, delete_argpair(x, z)) > delete_was3(w, delete_argpair(cons(y, x), cons(y, z))). } setting {solutions: 1 verbosity {models: brief stats: full job: brief }
Comments
There are no comments yet.