Extending Coinductive Logic Programming with Co-Facts

Abstract

We introduce a generalized logic programming paradigm where programs, consisting of facts and rules with the usual syntax, can be enriched by co-facts, which syntactically resemble facts but have a special meaning. As in coinductive logic programming, interpretations are subsets of the complete Herbrand basis, including infinite terms. However, the intended meaning (declarative semantics) of a program is a fixed point which is not necessarily the least, nor the greatest one, but is determined by co-facts. In this way, it is possible to express predicates on non well-founded structures, such as infinite lists and graphs, for which the coinductive interpretation would be not precise enough. Moreover, this paradigm nicely subsumes standard (inductive) and coinductive logic programming, since both can be expressed by a particular choice of co-facts, hence inductive and coinductive predicates can coexist in the same program. We illustrate the paradigm by examples, and provide declarative and operational semantics, proving the correctness of the latter. Finally, we describe a prototype meta-interpreter.

An inductive abstract semantics for coFJ

“…As we will detail later, the codefinition will be used instead of the standard method body (definition) in presence of a cycle, that is, when the same call is encountered twice. In this way, non-termination can be avoided 1 , and the semantics desired by the programmer can be achieved. In the codefiniton, besides parameters and this, the special variable any can be used as well.…”

“…Class ListFactory defines methods for building infinite lists. For instance, by invoking oneTwo(), we can build the list containing infinitely many alternating occurences of 1 and 2, abbreviated [1,2] in the following. Indeed, after an intermediate call twoOne(), the same call oneTwo() is encountered, and (corec) can be applied, which in this case returns an arbitrary value u, so we obtain 1:2:u for the initial call.…”

“…Indeed, after an intermediate call twoOne(), the same call oneTwo() is encountered, and (corec) can be applied, which in this case returns an arbitrary value u, so we obtain 1:2:u for the initial call. In the checking step, we should obtain in turn 1:2:u by evaluating oneTwo() assuming 1:2: as result of the cyclic call, and this only happens for = [1,2] .…”

“…Method allPos, checking that all the elements of a list of integers are positive, shows a more significant use of the codefinition. By invoking [1,2] .allPos(), when the cyclic call is detected, the codefinition returns true, hence the initial call as well. The checking step assuming true as result is successful.…”

“…Thus, when an already encountered call is found, this does not lead to nontermination as in standard semantics of recursion, since the cycle is detected, and the corresponding codefinition is evaluated. This mechanism has been fruitfully employed in other programming paradigms [1,7,10], and this operational semantics, being inductive, directly leads to a (semi-)algorithm.…”