Verifying Tight Logic Programs with anthem and Vampire

08/05/2020 ∙ by Jorge Fandinno, et al. ∙ 1

This paper continues the line of research aimed at investigating the relationship between logic programs and first-order theories. We extend the definition of program completion to programs with input and output in a subset of the input language of the ASP grounder gringo, study the relationship between stable models and completion in this context, and describe preliminary experiments with the use of two software tools, anthem and vampire, for verifying the correctness of programs with input and output. Proofs of theorems are based on a lemma that relates the semantics of programs studied in this paper to stable models of first-order formulas. Under consideration for acceptance in TPLP.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

This paper continues the line of research aimed at investigating the relationship between logic programs and first-order theories, which goes back to Keith Clark’s classical paper on program completion [Clark (1978)]. We are interested in extending that idea to input languages of answer set programming (ASP) [Brewka et al. (2011)] and in using it for the verification of ASP programs.

These programs are different from logic programs studied by Clark in two ways. First, their semantics is based on the concept of a stable model [Gelfond and Lifschitz (1988)], which is not equivalent to the completion semantics, unless some assumptions about the program are made, such as tightness [Fages (1994), Erdem and Lifschitz (2003)]. Second, ASP programs can include symbols for integers and arithmetic operations. Ways to extend completion to these constructs are proposed in two recent publications [Harrison et al. (2017), Lifschitz et al. (2020)].

It is essential for our purposes that, in ASP, we often deal with programs that accept an input and employ auxiliary predicates. Consider, for instance, the program

(1)

which encodes exact covers111 An exact cover of a collection  of sets is a subcollection  of  such that each element of the union of all sets in  belongs to exactly one set in . of a finite family of finite sets. It accepts an input, represented by a placeholder  and a predicate symbol ; is the number of sets, and the formula expresses that  belongs to the -th set. The predicate symbol represents the output, and is auxiliary.

In this paper, we extend the definition of program completion to programs with input and output in a subset of the input language of the ASP grounder gringo, state a theorem describing the relationship between stable models and completion in this context, and describe preliminary experiments with the use of two software tools, anthem [Lifschitz et al. (2018), Lifschitz et al. (2019)] and vampire [Kovács and Voronkov (2013)], for verifying the correctness of programs with input and output. A lemma that may be of independent interest relates the semantics of simple gringo programs to stable models of first-order formulas [Ferraris et al. (2011)]. It shows, in other words, that the approach to the semantics of logic programs advocated by lelipa08b is applicable to the subset of gringo studied here.

2 Review: Programs

The class of programs studied in this paper is the subset of the input language of gringo [Gebser et al. (2015)] discussed in earlier publications by Lifschitz et al. 2019; 2020.

We assume that three countably infinite sets of symbols are selected: numerals, symbolic constants, and program variables. We assume a 1-to-1 correspondence between numerals and integers; the numeral corresponding to an integer  is denoted by .

Program terms are defined recursively:

  • Numerals, symbolic constants, program variables, and the symbols and are program terms;

  • if , are program terms and is one of the operation names

    then is a program term.

If  is a term, then  is shorthand for .

A program term, or another syntactic expression, is ground if it does not contain variables. A ground expression is precomputed if it does not contain operation names (in other words, if it is a numeral, a symbolic constant, or one of the symbols or ).

We assume that a total order on precomputed program terms is chosen such that

  • is its least element and its greatest element,

  • for any integers  and , iff , and

  • for any integer  and any symbolic constant , .

An atom is an expression of the form , where  is a symbolic constant and  is a tuple of program terms. A literal is an atom possibly preceded by one or two occurrences of not. A comparison is an expression of the form , where , are program terms and is one of the comparison symbols

(2)

A rule is an expression of the form

(3)

where

  • is a conjunction (possibly empty) of literals and comparisons and

  • is either an atom (then, we say that (3) is a basic rule) or an atom in braces (then, (3) is a choice rule), or empty (then, (3) is a constraint).

A program is a finite set of rules.

For example, (1) is a program in the sense of this definition, except that the expression , strictly speaking, should be written as .

The semantics of programs uses a translation , which turns a program into a set of propositional combinations of precomputed atoms (Lifschitz et al., 2019, Section 3). For example, the result of applying  to the program

(4)

consists of the ground formulas

Using the translation , we define the semantics of programs as follows: A set of precomputed atoms is a stable model of a program  if it is a stable model (answer set) of in the sense of Ferraris 2005.

3 Review: Representing Programs by First-Order Theories

The translation  Lifschitz et al. (2019) converts a program into a finite set of first-order sentences with variables of two sorts. Besides program variables, which are meant to range over precomputed program terms, these sentences contain integer variables, which are meant to range over numerals. The second sort is a subsort of the first.

predicate symbol is a pair , where  is a symbolic constant and  is a nonnegative integer. About a program or another syntactic expression, we say that a predicate symbol  occurs in it if it contains an atom of the form .

For any program  consists of formulas over the two-sorted signature  including

  • all precomputed terms as object constants; a precomputed constant is assigned the sort integer iff it is a numeral;

  • the symbols , , and as binary function constants; their arguments and values have the sort integer;

  • all predicate symbols occurring in  and the comparison symbols other than equality as predicate constants.

An atomic formula can be abbreviated as . An atomic formula , where  is a comparison symbol, can be written as . Formulas are formed from atomic formulas using the propositional connectives

and the quantifiers and as usual in first-order languages with equality. We use  as shorthand for ,  as shorthand for , and as shorthand for .

Prior to defining , we define, for every program term , a formula , where is a program variable that does not occur in . That formula expresses, informally speaking, that is one of the values of . The definition is recursive:

  • if is a numeral, a symbolic constant, a program variable, , or , then is ;

  • if is , where is , , or , then is

    where , are fresh integer variables;

  • if is , then is

    where , , , are fresh integer variables;

  • if is , then is

    where , , , are fresh integer variables;

  • if is , then is

    where , , are fresh integer variables.

For example, is

and is

The other thing to do in preparation for defining is to define the translation  that will be applied to expressions in the body of the rule:

  • is

  • is

  • is

  • is

where each is a fresh program variable.

Now, we define

as the universal closure of the formula

where  is

  • if is ;

  • if is ;

  • if is empty;

where are fresh program variables.

For any program , stands for the set of formulas  for all rules  of . For example, the result of applying to program (4) is the pair of sentences

4 Main Lemma

The lemma stated in this section is used in the proofs of Theorems 1 and 2, which are stated later in Section 6. It relates the stable models of a program  to the stable models of the first-order theory .

Recall that, for any first-order sentence  and any list  of predicate symbols (other than equality), stands for the second-order sentence

(Ferraris et al., 2011, Section 2.3). The definition of  in that paper is given for formulas with one sort of variables, but its extension to many-sorted formulas is straightforward, and we will apply it here to the class of formulas defined in Section 3.

The models of are called the -stable models of . For a set  of first-order sentences, the -stable models of  are the -stable models of the conjunction of all formulas in .

For any program  and any set  of precomputed atoms,  stands for the interpretation of the signature  such that

  • the universe of the first sort of  is the set of all precomputed terms;

  • the universe of the second sort of  is the set of all numerals;

  • interprets every precomputed term  as ;

  • interprets as , and similarly for subtraction and multiplication;

  • interprets every precomputed atom as true iff it belongs to ;

  • interprets every atomic sentence , where  and  are precomputed terms, as true iff the relation  holds for the pair .

Main Lemma.

Let  be a program and let  be the list of all predicate symbols occurring in  other than the comparison symbols. A set  of precomputed atoms is a stable model of  iff  is a -stable model of .

Proofs are relegated to A.

5 Programs with Input and Output

5.1 Syntax

A program with input and output, or an io-program, is a quadruple

(5)

where

  • is a finite set of rules;

  •  is a finite set of symbolic constants, called the placeholders of (5);

  •  is a finite set of predicate symbols that do not occur in the heads of rules of ; they are called the input symbols of (5);

  •  is a finite set of predicate symbols that is disjoint from ; they are called the output symbols of (5).

The input and output symbols of an io-program are collectively called its public symbols; the predicate symbols occurring in the rules that are not public are called private. We also distinguish between public and private atoms, depending on whether their predicate symbols are public or private. Every set  of public atoms is the union of two disjoint sets—the set  of atoms in  that begin with an input symbol and the set  of atoms that begin with an output symbol.

As an example, consider the io-program with rules (1), the placeholder , the input symbol , and the output symbol . The only private symbol of  is .

By , we denote the part of the signature (Section 3) obtained from it by removing all private symbols. Formulas of that signature will be used in writing specifications.

Programs can be viewed as a special case of io-programs if we agree to identify a program  with the io-program (5) in which and are empty and  is the set of all predicate symbols that occur in the rules of .

5.2 Semantics

valuation for an io-program  is a function defined on the set of placeholders of  such that its values are precomputed terms different from placeholders. An input for  is a pair , where  is a valuation and  is a set of precomputed atoms that do not contain placeholders, such that the predicate symbol of each atom in  is an input symbol of .

For an io-program  and an input , we denote by the program consisting of

  • the rules obtained from the rules of  by replacing every occurrence of every placeholder  by the term  and

  • the facts .

About a set of precomputed atoms, we say that it is an io-model of an io-program  for an input  if it is the set of all public atoms of some stable model of .

For example, we can define an input for  by the conditions

With this input,  encodes the exact covers of the collection . The program consists of the rules

It has one stable model,

so that the only io-model of  is .

It is clear that atoms in an io-model do not contain private symbols. Furthermore, if  is an io-model of  for an input , then . This is clear from the fact that the only rules of containing input symbols in the head are the facts .

IO-models of io-programs also have a characterization in terms of first-order formulas similar to the characterization of stable models in the Main Lemma above (see Appendix A.2). The proof of this characterization is based on the aforementioned Main Lemma and results from Ferraris et al. (2009) and Cabalar et al. (2020). This is later used in the proofs of Theorems 1 and 2 below.

5.3 Specifications

In this paper, we are interested in io-programs written in response to formal specifications. A specification, as we understand this term, includes a list  of placeholders, a list  of input symbols, and a list  of output symbols that a future io-program  is required to have. (The choice of private symbols of  is left to the discretion of the programmer.) That part of the specification determines the set of valuations and inputs of  as well as the signature . A specification also includes two lists of sentences in first-order logic over that signature: a list  of assumptions and a list  of specs. The sentences in  do not contain output symbols. They are intended to describe the class of inputs that the author of the specification is interested in. The sentences in  are meant to describe the io-models that the future io-program is required to have for these inputs.

For example, a specification for the exact cover problem (see Footnote 1) may include the assumptions

(6)

where and are integer variables. They tell us that a “good” input describes the length and composition of a list of sets of precomputed atoms. Its specs may look like this:

(7)

These formulas describe the concept of an exact cover.

To give a precise definition of the semantics of specifications, we need to generalize the process of transforming a set  of precomputed atoms into the interpretation  defined in Section 4. This generalization takes into account the fact that placeholders may be “reinterpreted” by a valuation. For any set  of precomputed public atoms that do not contain placeholders and any valuation , we denote by the interpretation of the signature  such that

  • the universe of the first sort of  is the set of all precomputed terms;

  • the universe of the second sort of  is the set of all numerals;

  • interprets every placeholder  as  and every other precomputed term  as ;

  • interprets as , and similarly for subtraction and multiplication;

  • interprets every precomputed atom that does not contain placeholders as true iff it belongs to ;

  • interprets every atomic sentence , where  and  are precomputed terms different from placeholders, as true iff the relation  holds for the pair .

In the exact cover example,  interprets the placeholder  as . This interpretation satisfies the first of assumptions (6) iff  is a nonnegative numeral.

We say that  implements the specification with assumptions  and specs  if, for every valuation  and every set  of precomputed public atoms without placeholders such that satisfies ,

is an io-model of  for the input iff  satisfies .

In the next section, we show that this condition can be sometimes established by proving a sentence in a first-order theory. This is how anthem works.

6 Completion and Tightness

6.1 Completed Definitions

The definition of a predicate symbol  in an io-program  is the set of all rules of  that have the forms

(8)

and

(9)

If the definition of  in  consists of rules , then the formula representations of these rules are constructed as follows. Take fresh program variables . If  is (8), then  is the formula

(see Section 3 for the definitions of and ). If  is (9), then  is the formula

(10)

We are ready to define “completed definitions” of predicate symbols. Completed definitions are generally second-order formulas—the private symbols of  are represented in them by predicate variables.

Let  be an io-program with private symbols . Choose pairwise distinct predicate variables and take a predicate symbol  that occurs in  and is different from its input symbols. The completed definition of  in  is obtained from the formula

(11)

where  is the list of all variables occurring in rule  after substituting for .

For example, the completed definition of in  is

(12)

It can be equivalently rewritten as

6.2 Completion

For a constraint , its formula representation is defined as the formula obtained from the universal closure of by substituting for . For example, the formula representation of the second constraint of  is obtained from the formula

by substituting a predicate variable for the predicate constant . It can be equivalently rewritten as

(13)

The completion of an io-program  is the sentence , where are the predicate variables corresponding to the private symbols of , as described above, and  is the conjunction of

  • the completed definitions of all predicate symbols occurring in  other than its input symbols and

  • the formula representations of all constraints in .

Note that this sentence does not contain any of the private symbols of . In other words, it is a second-order sentence over the signature  (Section 5.1).

For example, the predicate completion of  is

where  is the completed definition (12) of , is the completed definition of , and , are the formula representations of the two constraints.

Theorem 1.

If  is an io-model of an io-program  for an input , then the interpretation  satisfies .

6.3 Tight Programs

The predicate dependency graph of an io-program is the directed graph that

  • has the predicate symbols occurring in rules of  as its vertices and

  • has an edge from to  if there is a rule  in  such that  occurs in the head of  and  occurs in the body of .

The edge from  to  in the predicate dependency graph is positive if there is a rule  in  such that  occurs in the head of  and  occurs in an atom in the body of  that is not preceded by .

An io-program is tight if its predicate dependency graph has no cycles consisting of positive edges.

Theorem 2.

For any tight io-program  and any set  of precomputed public atoms without placeholders,  is an io-model of  for an input  iff satisfies and .

This theorem shows that, in application to tight io-programs, the semantics of specifications (Section 5.3) can be characterized in terms of completion: A tight io-program  implements the specification with assumptions  and specs  iff, for every valuation  and every set  of precomputed public atoms without placeholders, the interpretation  satisfies the sentence

(14)

(We identify a list of sentences with the conjunction of its members.)

An interpretation of the signature  is standard if it can be represented in the form  for some set  of precomputed public atoms without placeholders and some valuation . We can then say that a tight io-program  implements the specification with assumptions  and specs  iff sentence (14) is satisfied by all standard interpretations.

The automation of reasoning about formulas of form (14) is difficult because has, generally, bound predicate variables. We will now discuss a special case when reasoning about such formulas can be reduced to first-order reasoning.

6.4 Private Recursion

Recall that the completion of an io-program  is a sentence of the form , where is a list of predicate variables (Section 6.2). That list has the same length  as the list  of the private symbols of . Formula  is a conjunction that includes, among its conjunctive terms, the completed definitions of . Denote the conjunction of all other conjunctive terms of  by . Then, the completion of  can be written as

(15)

About an io-program , we say that it uses private recursion if

  • its predicate dependency graph has a cycle such that every vertex in it is a private symbol or

  • it includes a choice rule with a private symbol in the head.

Theorem 3.

If an io-program  does not use private recursion, then its completion is equivalent to

(16)

From this theorem, we can conclude that, if  does not use private recursion, sentence (14) is equivalent to

and consequently to

(17)

The procedure used by anthem for program verification is applicable to an io-program if it is tight and does not use private recursion. The procedure is based on the following idea. We choose a set of axioms—sentences over the signature  that are satisfied by all standard interpretations. This set may include, for instance, the formulas and . It may include also the formula , where  and are distinct symbolic constants, unless at least one of them is a placeholder. To establish that  implements the given specification, anthem verifies that the axioms entail sentence (17). This can be accomplished by first-order reasoning—by verifying that the axioms entail the sentence obtained from (17) by replacing the bound predicate variables with distinct predicate constants that do not occur in the axioms. The predicate constants used by anthem are actually the private predicate symbols from the rules of , so that the formula derived by anthem from the axioms is

Proof search is performed by the resolution theorem prover vampire. The task is divided into two parts: deriving the specs  from the axioms, the assumptions , and the formulas (“forward direction”) and deriving  from the axioms, the assumptions , and the formulas (“backward direction”).

7 Verifying Tight Logic Programs with anthem

Let us return to the exact cover problem, which we encoded in rules (1) and represented as io-program  earlier. We would like to show that this program implements specification (7) under the assumptions stated in (6). This verification can be automated with anthem 1.0.222https://github.com/potassco/anthem/releases To this effect, anthem reads a logic program and a specification, checks that the program is tight and does not contain private recursion, generates the program’s completion, and then performs automated proof searches trying to establish that the program actually implements the given specification.

As the input program, we can simply pass rules (1) to anthem in the input language of gringo. For the specification, anthem accepts files in a custom specification file format. Specification files may contain multiple types of statements. input and output statements specify input predicates and placeholders as opposed to output predicates. Axioms, assumptions and specs are expressed by axiom, assume, and spec statements, respectively. anthem’s specification file format has a simple syntax for such formulas. This format is a concise form of the segment of the TPTP language Sutcliffe (2017) that is required for expressing specifications.

Similar to the input language of gringo, identifiers starting with a lowercase letter are interpreted as predicate and object constants, while variables are denoted by identifiers starting with an uppercase letter. An important distinction is that variables starting with letters I, J, K, L, M, or N are implicitly assumed to be integer variables—as opposed to program variables, which must start with U, V, W, X, Y, or Z. anthem shows an error message if variables are used that start with letters not listed above. Terms may contain integer arithmetics with a syntax close to gringo. In addition to that, the keywords not, and, or, ->, <->, exists, and forall denote the common operators of first-order logic.

We can encode specification (7) and assumptions (6) in this format, as shown in Figure 1.

input: n -> integer, s/2.
output: in_cover/1.
assume: n >= 0.
assume: forall Y (exists X s(X, Y) -> exists I (Y = I and I >= 1 and I <= n)).
spec: forall Y (in_cover(Y) -> exists I (Y = I and I >= 1 and I <= n)).
spec: forall X (exists Y s(X, Y) -> exists Y (s(X, Y) and in_cover(Y))).
spec: forall Y, Z (exists X (s(X, Y) and s(X, Z)) and in_cover(Y) and in_cover(Z)
                   -> Y = Z).
Figure 1: A specification file to verify that a program encoding the exact cover problem fulfills specification (7) under assumptions (6). First, is declared a placeholder using an input statement. The -> integer notation instructs anthem to represent by an integer variable internally. Next, the input and output predicates of ( and , respectively) are declared. The assume and spec statements encode assumptions (6) and specs (7).

If we give this specification to anthem along with the exact cover program encoded in (1), anthem first generates the program’s completion and shows it to the user (see Figure 2).

forall X (covered(X) <-> exists N (in_cover(N) and s(X, N)))
forall X (in_cover(X) <-> in_cover(X) and exists N (1 <= N and N <= n and X = N))
forall N1, N2, X not (N1 != N2 and in_cover(N1) and in_cover(N2)
                      and s(X, N1) and s(X, N2))
forall X, N not (s(X, N) and not covered(X))
Figure 2: anthem generates the completion of the input program—here, , the exact cover problem encoded by rules (1). The first two lines contain the completed definitions of and . They are followed by the two translated constraints. Note that anthem applies basic equivalent transformations to simplify the completion formulas. For example, the completed definition of shown here corresponds to formula (12), but the integer variables and were eliminated by anthem. The last line matches formula (13), the formula representation of the second constraint of .

This is done as described in Section 6.2. Afterward, anthem verifies very quickly that the program indeed implements the specification in Figure 1 using the theorem prover vampire and informs the user accordingly.333 When running vampire 4.4 with the options --mode casc and --cores 8 on a computer with an Intel Core i7-7700K CPU and 16 GB RAM, the equivalence proof completes within a total of 0.37 seconds.

To accomplish this, anthem splits the equivalence verification task into two parts, as mentioned at the end of Section 6.4. In either direction, anthem starts with a set of presupposed formulas and performs one proof step for each formula to verify. For each proof step, anthem devises a program in the TFF (“typed first-order formula”) segment of the TPTP language. In this TPTP program, all presupposed formulas are represented as TPTP axioms, and the formula to verify in this proof step is used as the conjecture. anthem then passes this TPTP program to vampire. If a proof step is successful within a predefined time limit, the formula is added to the list of presupposed formulas and the next proof step is conducted. The fact that anthem uses the TPTP format to communicate with vampire is completely hidden from the user.

In some cases, vampire is incapable of verifying the equivalence of a specification to a program directly and within a reasonable time frame, for which there are two possible explanations. First, the set of axioms known to vampire might not be sufficient to perform the proof, and second, it might be necessary to further guide vampire’s proof search by providing helper lemmas. To that end, anthem allows users to supply additional axioms and helper lemmas with the axiom and lemma directives, respectively. anthem verifies helper lemmas in the given order before the specs or the completion of the program. The usage of axioms and helper lemmas can be seen in a second example, a specification for programs that compute the floor of the square root of an integer  shown in Figure 3 and the implementation in Figure 4.

input: n -> integer.
assume: n >= 0.
output: q/1.
spec: exists N (forall X (q(X) <-> X = N) and N >= 0
                and N * N <= n and (N + 1) * (N + 1) > n).
Figure 3: A specification for programs calculating the floor of the square root of an integer .
p(X) :- X = 0..n, X * X <= n.
q(X) :- p(X), not p(X + 1).
Figure 4: A program meant to implement the specification in Figure 3.

anthem and vampire verify the equivalence between this specification and program only when supplying an axiom unknown to vampire and a list of helper lemmas (shown in Figure 5).

axiom: p(0) and forall N (N >= 0 and p(N) -> p(N + 1))
       -> forall N (N >= 0 -> p(N)).
lemma(forward): forall X (p(X) <-> exists N (X = N and N >= 0 and N * N <= n)).
lemma(forward): forall X (q(X) <-> exists N2 (X = N2 and N2 >= 0 and N2 * N2 <= n
                                              and (N2 + 1) * (N2 + 1) > n)).
lemma(forward): forall N1, N2 (N1 >= 0 and N2 >= 0 and N1 < N2
                               -> N1 * N1 < N2 * N2).
lemma(forward): forall N (N >= 0 and p(N + 1) -> p(N)).
lemma(forward): not p(n + 1).
lemma(forward): forall N1, N2 (q(N1) and N2 > N1 -> not q(N2)).
lemma(forward): forall N (N >= 0 and not p(N + 1) -> (N + 1) * (N + 1) > n).
lemma(backward): forall N1, N2 (N1 >= 0 and N2 >= 0 and N1 * N1 <= N2 * N2
                                -> N1 <= N2).
lemma(backward): forall N (p(N) <-> 0 <= N and N <= n and N * N <= n).
lemma(backward): forall N (not p(N) and N >= 0 -> N * N > n).
lemma(backward): forall N (N >= 0 -> N * N < (N + 1) * (N + 1)).
lemma(backward): forall N1, N2 (p(N1) and not p(N2) and N2 >= 0 -> N1 < N2).
lemma(backward): forall N1, N2 (p(N1) and not p(N1 + 1) and p(N2)
                                and not p(N2 + 1) -> N1 = N2).
Figure 5: vampire is unable to verify the equivalence of the specification in Figure 3 to the program in Figure 4 in a reasonable time frame. This can be addressed by supplying helper lemmas using the lemma keyword, where forward and backward instruct anthem only to apply lemmas in the respective part of the equivalence proof. With these helper lemmas, vampire can perform the backward direction of the equivalence proof task but is still unable to verify the forward direction. To address this, the set of axioms is manually extended by a fact that is not known to vampire, an instance of induction. Such axioms can be added with axiom statements.

While anthem 1.0 introduces the mode of operation described in the present paper, earlier versions of anthem allowed users to try to prove that the stable models of a (not necessarily tight) program satisfy a specification Lifschitz et al. (2020). This functionality is retained as a second mode of operation in anthem 1.0.

8 Conclusions

This paper has four main contributions. First, we presented an extended definition of completion for programs with input and output in a subset of the input language of gringo. Such programs are similar to lp-functions, defined by Gelfond and Przymusinska 1996, except that we allow an input to include the values of placeholders. Also, they are closely related to smodels program modules Oikarinen and Janhunen (2009). Second, we stated a result describing the relationship between stable models and completion in this context. It uses the theory of stable models of infinitary formulas by Truszczyński (2012) and Harrison et al. (2017). Third, we proposed a new theory of formal specifications for programs in the input language of gringo. Fourth, we presented preliminary experiments with the new version of anthem, a software tool used in combination with a theorem prover to verify that programs with input and output implement a specification. Only few theorem provers support both the typed first-order form of TPTP and integer arithmetics, and vampire was chosen because its performance outclassed other provers in our early experiments. In later experiments, cvc4 emerged as a possible alternative with similar performance to vampire, and we consider using cvc4 in the future. As another direction of future work, we would like to extend the subset of the input language of gringo supported by anthem, in particular, by simple forms of aggregates.

Acknowledgments

We thank Michael Gelfond and the anonymous referees for their valuable comments. Jorge Fandinno is funded by the Alexander von Humboldt Foundation.

References

  • Brewka et al. (2011) Brewka, G., Eiter, T., and Truszczyński, M. 2011. Answer set programming at a glance. Communications of the ACM 54, 12, 92–103.
  • Cabalar et al. (2020) Cabalar, P., Fandinno, J., and Lierler, Y. 2020. Modular answer set programming as a formal specification language. Theory and Practice of Logic Programming, this volume.
  • Clark (1978) Clark, K. 1978. Negation as failure. In Logic and Data Bases, Plenum Press, 293–322.
  • Erdem and Lifschitz (2003) Erdem, E. and Lifschitz, V. 2003. Tight logic programs. Theory and Practice of Logic Programming 3, 4-5, 499–518.
  • Fages (1994) Fages, F. 1994. Consistency of Clark’s completion and the existence of stable models. Journal of Methods of Logic in Computer Science 1, 51–60.
  • Ferraris (2005) Ferraris, P. 2005. Answer sets for propositional theories. In Proceedings of the 8th International Conference on Logic Programming and Nonmonotonic Reasoning, Springer, 119–131.
  • Ferraris et al. (2011) Ferraris, P., Lee, J., and Lifschitz, V. 2011. Stable models and circumscription. Artificial Intelligence 175, 1, 236–263.
  • Ferraris et al. (2009) Ferraris, P., Lee, J., Lifschitz, V., and Palla, R. 2009. Symmetric splitting in the general theory of stable models. In Proceedings of the 21st International Joint Conference on Artificial Intelligence, AAAI/MIT Press, 797–803.
  • Gebser et al. (2015) Gebser, M., Harrison, A., Kaminski, R., Lifschitz, V., and Schaub, T. 2015. Abstract Gringo. Theory and Practice of Logic Programming 15, 4-5, 449–463.
  • Gelfond and Lifschitz (1988) Gelfond, M. and Lifschitz, V. 1988. The stable model semantics for logic programming. In Proceedings of the 5th International Conference on Logic Programming, MIT Press, 1070–1080.
  • Gelfond and Przymusinska (1996) Gelfond, M. and Przymusinska, H. 1996. Towards a theory of elaboration tolerance: Logic programming approach.

    International Journal of Software Engineering and Knowledge Engineering

     6, 1, 89–112.
  • Harrison et al. (2017) Harrison, A., Lifschitz, V., Pearce, D., and Valverde, A. 2017. Infinitary equilibrium logic and strongly equivalent logic programs. Artificial Intelligence 246, 22–33.
  • Harrison et al. (2017) Harrison, A., Lifschitz, V., and Raju, D. 2017. Program completion in the input language of GRINGO. Theory and Practice of Logic Programming 17, 5-6, 855–871.
  • Kovács and Voronkov (2013) Kovács, L. and Voronkov, A. 2013. First-order theorem proving and Vampire. In Proceedings of the 25th International Conference on Computer Aided Verification, Springer, 1–35.
  • Lee et al. (2008) Lee, J., Lifschitz, V., and Palla, R. 2008. A reductive semantics for counting and choice in answer set programming. In Proceedings of the 23rd National Conference on Artificial Intelligence, AAAI Press, 472–479.
  • Lifschitz et al. (2018) Lifschitz, V., Lühne, P., and Schaub, T. 2018. anthem: Transforming gringo programs into first-order theories (preliminary report). In Proceedings of the 11th Workshop on Answer Set Programming and Other Computing Paradigms,
  • Lifschitz et al. (2019) Lifschitz, V., Lühne, P., and Schaub, T. 2019. Verifying strong equivalence of programs in the input language of GRINGO. In Proceedings of the 15th International Conference and Symposium of Logic Programming and Nonmonotonic Reasoning, Springer, 270–283.
  • Lifschitz et al. (2020) Lifschitz, V., Lühne, P., and Schaub, T. 2020. Towards verifying logic programs in the input language of CLINGO. In Essays Dedicated to Yuri Gurevich on the Occasion of His 80th Birthday, Springer, 190–209.
  • Oikarinen and Janhunen (2009) Oikarinen, E. and Janhunen, T. 2009. A translation-based approach to the verification of modular equivalence. Journal of Logic and Computation 19, 4, 591–613.
  • Sutcliffe (2017) Sutcliffe, G. 2017. The TPTP problem library and associated infrastructure.

    Journal of Automated Reasoning

     59, 4, 483–502.
  • Truszczyński (2012) Truszczyński, M. 2012. Connecting first-order ASP and the logic FO(ID) through reducts. In Correct Reasoning: Essays on Logic-Based AI in Honour of Vladimir Lifschitz, Springer, 543–559.

Appendix A Proofs

a.1 Main Lemma

Let us now extend the correspondence between stable models defined in terms of the SM operator and infinitary logic Truszczyński (2012) to the above two-sorted case. We also allow formulas to contain extensional predicate symbols, which are not considered in Truszczyński (2012).

We use the following notation. By , we denote the set of all numerals, and by , we denote the set of all precomputed terms. For an interpretation  and a list  of predicate symbols, by , we denote the set of precomputed atoms satisfied by  where .

Let  be a partition of the predicate symbols in the signature. Then, the grounding of a sentence  with respect to an interpretation  and a set of intensional predicate symbols  (and extensional predicate symbols ) is defined as follows:

  • ;

  • for , ;

  • for , if

    and otherwise;

  • if and otherwise;

  • if is , , or ;

  • if is a program variable;

  • if is a program variable;

  • if is an integer variable;

  • if is an integer variable.

For a theory , we define .

Definition 1.

Let  be a theory and  be a list of predicate symbols. Then, an interpretation  is called an INF--stable model of  if  is a stable model of  in the sense of Definition 1 in Truszczyński (2012).

Any term, formula, or theory over the two-sorted signature  can be seen as one-sorted if we do not assign sorts to variables. On the other hand, some one-sorted terms and formulas cannot be viewed as terms or formulas over ; for instance, the one-sorted term , where and  are program variables, is not a term over . We will refer to terms, formulas, and theories over  as two-sorted. One-sorted interpretations are defined as usual in first-order logic, with integer and program variables ranging over the same domain. One-sorted -stable models and one-sorted INF--stable models are defined as -stable models and INF--stable models (see Section 4), respectively, but using one-sorted interpretations rather than two-sorted ones. We also say that two theories are one-sorted-equivalent if both theories have exactly the same one-sorted models. The following is a special case of Theorem 5 in Truszczyński (2012) restricted to our one-sorted language.

Proposition 1.

Let  be a finite theory and