1 Introduction
We present ANTHEM 2.0, the latest system developed as part of the “Answer Set Programming + Theorem Proving” (ANTHEM) project. This system consolidates the findings and functionalities of previous prototypes into a stable tool for verifying programs in the paradigm of Answer Set Programming (ASP). The ANTHEM 2.0 system (in the sequel we drop 2.0 when referring to this system) can process ASP programs written in a subset of the input language of the grounder GRINGO (Gebser et al. Reference Gebser, Harrison, Kaminski, Lifschitz and Schaub2015). This subset, described by Fandinno et al. (Reference Fandinno, Lifschitz and Temple2020), is referred to as MINI-GRINGO. MINI-GRINGO programs can contain arithmetic operations and simple choice rules, but not aggregates. We can use ANTHEM to verify two important equivalence relations between ASP programs: strong equivalence and external equivalence. ASP programs
$\Pi _1$
and
$\Pi _2$
are called strongly equivalent if replacing
$\Pi _1$
by
$\Pi _2$
within any larger program does not affect its stable models (Lifschitz et al. Reference Lifschitz, Pearce and Valverde2001). For example, the one-rule successor programs
\begin{gather} {\texttt {q(X+1) :- p(X).} \qquad \qquad \textrm {and} \qquad \qquad \texttt {q(X) :- p(X-1).}} \end{gather}
are strongly equivalent. The systems for verifying strong equivalence designed in the past (Janhunen and Oikarinen Reference Janhunen, Oikarinen, Lifschitz and Niemelä2004; Valverde Reference Valverde, Alferes and Leite2004; Chen et al. Reference Clark, Gallaire and Minker2005; Oetsch et al. Reference Oetsch, Seidl, Tompits, Woltran, Seipel, Hanus and Wolf2009) are limited to ground programs; ANTHEM does not suffer this limitation.
Listing 1. A MINI-GRINGO program, primes.1.lp.
External equivalence is equivalence with respect to a “user guide” – a description of how the programs are meant to be used (Fandinno et al. Reference Fandinno, Lifschitz, Gaggl, Martinez and Ortiz2023). Consider, for instance, the programFootnote
1
in Listing 1, which finds all primes within an interval
$\{a,\ldots ,b\}$
with
$a\gt 1$
. Its intended use can be described by the user guide in Listing 2.
Listing 2. A user guide for the primes problem.
It tells us that when we run the program, we are expected to specify appropriate values for the placeholders a and b. Furthermore, it says that the output of the program consists of atoms in the stable model that contain prime/1; any other atoms of the stable model are auxiliary (“private”).
ASP programs
$\Pi _1$
and
$\Pi _2$
are (externally) equivalent with respect to a user guide if, for any input that is permitted by the user guide, they produce the same output. For example, the program in Listing 1 is externally equivalent to the more efficient program
with respect to the user guide defined above, even though the stable models of the two programs differ with respect to the auxiliary predicate composite/1.
In the special case when programs do not accept inputs and have no auxiliary predicates, external equivalence means simply that the programs have the same stable models. We call this weak equivalence. If we allow auxiliary predicates and inputs, but we restrict the inputs to not contain placeholders, then external equivalence becomes a special case of relativized uniform equivalence with projection (Oetsch and Tompits Reference Oetsch, Tompits, de la Banda and Pontelli2008).
In addition to checking equivalence of programs, ANTHEM can verify the adherence of an ASP program to a specification written in classical first-order logic. For example, the formula below written in the custom language of ANTHEM captures the formal property encoded in the preceding example:
This formula contains variables of two sorts: a general variable named X and integer variables D and M. The sort of the variable is indicated by the suffix $g or $i for the sorts general and integer, respectively. Analogously to how it checks external equivalence between programs, ANTHEM can verify that the prime/1 predicate as defined by Listing 1 possesses the property encoded by the specification with respect to the user guide in Listing 2.
Using ANTHEM to verify external equivalence between MINI-GRINGO programs involves
-
• transforming rules into first-order sentences,
-
• forming program completions,
-
• reducing the tasks described above to first-order theorem proving, and
-
• using the theorem prover VAMPIRE (Kovács and Voronkov Reference Kovács, Voronkov, Sharygina and Veith2013) for proof search.
Fandinno et al. (Reference Fandinno, Lifschitz and Temple2020) describe the original system that pioneered some of the presented ideas. We refer to this system as ANTHEM-1. It was designed with the goal of verifying the adherence of a program to a specification written in first-order logic. A related “translate and verify” system, ANTHEM-SE, was developed by Lifschitz et al. Reference Lifschitz, Lühne, Schaub, Balduccini, Lierler and Woltran(2019) for verifying strong equivalence and extended to programs with negation by Heuer (Reference Heyting2020). Finally, the ANTHEM-P2P system (Fandinno et al. Reference Fandinno, Lifschitz, Gaggl, Martinez and Ortiz2023) was an application built on top of the ANTHEM-1 system for verifying external equivalence of programs.
Now, we present ANTHEM 2.0, which combines and extends the functionalities of the previous systems within a new, standalone library and command-line application. Our system helps users verify strong, external, and weak equivalence of programs, analyze properties of programs such as tightness and regularity, and translate programs into the syntax of many-sorted first-order logic. The theory behind ANTHEM has been given a thorough treatment in previous publications, and we refer to these publications for theoretical concepts instead of redefining them here.
2 Preliminaries: Program and “Target” languages
The ABSTRACT GRINGO (AG) language (Gebser et al. Reference Gebser, Harrison, Kaminski, Lifschitz and Schaub2015) is a theoretical representation of the input language accepted by the widely used ASP solver CLINGO. The fragments of AG studied in the context of ANTHEM are commonly referred to as MINI-GRINGO – this is the subset of AG for which an appropriate translation to the syntax of first-order logic has been widely studied. In this paper, we follow the definition presented by Fandinno et al. (Reference Fandinno, Lifschitz and Temple2020) when we refer to MINI-GRINGO. A MINI-GRINGO program consists of basic rules, choice rules, and constraints:
\begin{align*} H\;\hbox{:-}\; B_1,\ldots ,B_n.\qquad \qquad \qquad \{H\}\;\hbox{:-}\; B_1,\ldots ,B_n.\qquad \qquad \qquad \;\hbox{:-}\; B_1,\ldots ,B_n. \end{align*}
Here
$H$
is an atom and each
$B_i$
(
$1 \leq i \leq n$
) is either an atom, possibly preceded by one or two negation-as-failure symbols, or a comparison. The fundamental task of ANTHEM consists of verifying the correctness of MINI-GRINGO programs (Section 4). To achieve this goal, the system implements multiple translations between representations of these programs in different languages. One of these languages is the TPTP format, which is a standard format for Automated Theorem Prover (ATP) systems (Sutcliffe Reference Sutcliffe2017). Hence, the different verification tasks that ANTHEM can perform are based on the translation of MINI-GRINGO programs into a language of logical formulas, running an ATP system on a task assembled from the translated program(s), and interpreting the results of the ATP system to provide an answer to the verification task. Transforming an equivalence claim about MINI-GRINGO programs into a series of TPTP problems is a non-trivial process and in general requires several intermediate transformations. Thus, at the heart of ANTHEM is a logical language, which we call here simply the target language, that supports all these intermediate transformations. Theories written in this language may be interpreted under the semantics of classical first-order logic or the logic of here-and-there (HT; Heyting Reference HUTCHISON, Kanade, Kittler, Kleinberg, Mattern, Mitchell, Naor, Nierstrasz, Pandu Rangan, Steffen, Sudan, Terzopoulos, Tygar, Vardi, Weikum, Baral, Greco, Leone and Terracina1930), but syntactically this is a first-order language with variables of three sorts: (1) a sort whose universe contains integers, symbolic constants, and special symbols #inf and #sup, (2) a subsort corresponding to integers, and (3) a subsort corresponding to symbolic constants.
Variables ranging over these sorts are written as “Name$sort”, where Name is a capitalized word and sort is one of the sorts defined above. Certain abbreviations are permitted:
-
• a general variable named V can be written as V, V$g, or V$general;
-
• an integer variable named X can be written as X$, X$i, or X$integer; and
-
• a symbol variable named S can be written as S$s or S$symbol.
Like ABSTRACT GRINGO and MINI-GRINGO, the target language is a theoretical language – a formula written in this language can be printed as a series of Unicode characters in different ways. For example, the target language formula
\begin{gather} \forall X ( \exists I (I = X \wedge p(I)) \rightarrow q(X)) \end{gather}
(in which
$X$
is a general variable and
$I$
is an integer variable) expresses that
$q$
holds for all
$X$
such that
$X$
is an integer for which
$p$
holds. This formula can be read or displayed in a custom ANTHEM syntax as follows:
ANTHEM can also display target language formulas in the TPTP syntax. The preceding formula (2) is formatted in TPTP as
In Section 4, we show how verification tasks are handled by extending ANTHEM’s custom syntax for target language formulas with meta-level declarative statements controlling proof search – we call this the control language.
3 Translating logic programs and formulas with ANTHEM
ANTHEM supports (1) translations from ASP programs into logical formulas, and (2) transformations of logical formulas within the target language.
3.1 Translating ASP programs into the target language
Past versions of the ANTHEM system (Fandinno et al. Reference Fandinno, Lifschitz and Temple2020; Heuer Reference Heyting2020) relied exclusively on a translation known as
$\tau ^*$
(Lifschitz et al. Reference Lifschitz, Lühne, Schaub, Balduccini, Lierler and Woltran2019) that transformed MINI-GRINGO programs into their formula representations. To accommodate features such as partial arithmetic functions,
$\tau ^*$
produces complex formulas that are not easily understood. However, a broad fragment of MINI-GRINGO programs does not require such complexity. For a class of rules called regular, a more natural translation
$\nu$
has been developed to produce formulas that are more human-readable while maintaining equivalence to their
$\tau ^*$
counterparts (Lifschitz Reference Lifschitz, Faber, Friedrich, Gebser and Morak2021). ANTHEM employs both the
$\tau ^*$
translationFootnote
2
and natural translation
$\nu$
. For example, the natural translations of successor programs (1) are
For rules that do not meet the requirements of regularity, ANTHEM falls back on
$\tau ^*$
to obtain their formula representations. Translating nonregular rules is a non-trivial task; for example, consider the rule
which is not regular due to the partial function of division. We can apply translation
$\tau ^*$
to this rule using the command
which produces the output
Interestingly,
$\tau ^*$
and
$\nu$
can be safely combined by applying
$\nu$
to every regular rule and
$\tau ^*$
to the rules that are not regular. Such a transformation is denoted
$\mu$
(Fandinno and Lifschitz Reference Fandinno and Lifschitz2023b). ANTHEM supports
$\mu$
,
$\nu$
, and
$\tau ^*$
as translation options:
3.2 Transformations within the target language
To support the verification of ASP programs, ANTHEM provides two transformations that can be applied to logical formulas within the target language. Each of these transformations provides as output a formula whose validity in classical first-order logic supports some of the verification tasks described in Section 4.
3.2.1 From here-and-there satisfaction to classical satisfaction
Stable models of MINI-GRINGO programs can be described in terms of the logic of HT by selecting the so-called equilibrium models (Pearce Reference Pearce2006). This connection has inspired a line of research into translating programs written in ASP input languages into HT theories whose equilibrium models correspond to the answer sets of the original program. Interestingly, for the translations concerning this paper, two programs are strongly equivalent if and only if their formula representations are equivalent in HT (Lifschitz et al. Reference Lifschitz, Pearce and Valverde2001). This gives us a method for verifying strong equivalence.
To reduce the task of reasoning about HT theories to reasoning over classical theories, transformations have been proposed that “embed” the behavior of HT-satisfaction into classical satisfaction of transformed formulas. One of the first representations of this process in the ASP literature can be attributed to Pearce et al. Reference Pearce, Tompits, Woltran, Brazdil and Jorge(2001), who describes a transformation that converts propositional HT theories into classical theories over an extended signature. A generalization
$\gamma$
of this translation to formulas with variables was studied by Heuer (Reference Heyting2020) and by Fandinno and Lifschitz (Reference Fandinno and Lifschitz2023b). The
$\gamma$
transformation was fundamental to the design of ANTHEM-SE, which implemented a procedure for strong equivalence checking. For example, if
$R$
is the rule
\begin{align*} \texttt {q(X,Y+1) :- p(X,Y).} \end{align*}
then
$\nu R$
is
\begin{gather*} \forall X N (p(X, N) \rightarrow q(X, N + 1)). \end{gather*}
where
$N$
is an integer variable. The result of applying
$\gamma$
to this formula is
\begin{gather*} \forall X N ((hp(X, N) \rightarrow hq(X, N + 1)) \wedge (tp(X, N) \rightarrow tq(X, N + 1))). \end{gather*}
The classical models of
$\gamma (\nu R)$
satisfying the additional axioms
\begin{gather*} \forall X Y (hp(X, Y) \rightarrow tp(X, Y)) \qquad \text{ and }\qquad \forall X Y (hq(X, Y) \rightarrow tq(X, Y)) \end{gather*}
correspond to the HT models of
$\nu R$
. In terms of Kripke models, new predicates
$hp/1$
and
$hq/1$
represent satisfaction in the “here” world;
$tp/1$
and
$tq/1$
represent satisfaction in the “there” world. We call such additional axioms ordering sentences.
The
$\gamma$
transformation plays a central role in the automated verification of strong equivalence (Section 4.1).
3.2.2 Completion
For the so-called tight programs (Fandinno et al. Reference Fandinno, Lifschitz and Temple2020, Section 6), Clark’s Completion (Clark Reference Fandinno, Hansen, Lierler, Lifschitz and Temple1978) characterizes the stable models of a logic program as the models of a classical first-order theory. Since its introduction, the idea of completion has been widely generalized. In the context of ANTHEM, we view completion as a transformation on top of target language theories of a certain form. These so-called completable theories can be transformed according to the completion procedure described by Fandinno et al. (Reference Fandinno, Lifschitz and Temple2024) into first-order theories. The
$\tau ^*$
transformation is designed to produce completable theories when applied to MINI-GRINGO programs. For instance, we can compute the completion of the program choice.1.lp consisting of the rule
$\{q(X)\} \;\hbox{:-}\; p(X)$
by passing the output of the
$\tau ^*$
translation to the completion operator:
This produces the output
Completion allows us to use first-order theorem provers to verify the external equivalence of programs meeting certain restrictions, such as tightness (Section 4.2). We can confirm that our program is tight with the command
4 Verifying logic programs with ANTHEM
The fundamental task of ANTHEM consists of formally verifying properties of MINI-GRINGO programs. This section describes the three verification tasks that ANTHEM can perform: strong equivalence, external equivalence, and specification adherence.
4.1 Strong equivalence
The strong equivalence of two programs
$\Pi _1$
and
$\Pi _2$
can be established by deriving the equivalence
$\gamma (\tau ^*\Pi _1) \leftrightarrow \gamma (\tau ^*\Pi _2)$
(or, equivalently,
$\gamma (\mu \Pi _1) \leftrightarrow \gamma (\mu \Pi _2)$
) from the associated ordering sentences. ANTHEM accomplishes this by constructing a series of subproblems for an ATP system to solve. To illustrate this process, consider the encoding of the property
Listing 3. The program transitive.1.lp.
“q is transitive on the domain of p” given in Listing 3 (Harrison et al. Reference Heuer2017), and a refactoring of this program (transitive.2.lp) that replaces the second rule with the constraint
\begin{align} \texttt {:- q(X,Y), q(Y,Z), not q(X,Z), p(X), p(Y), p(Z).} \end{align}
We can verify their strong equivalence by invoking ANTHEM with an instruction to use
$\mu$
for obtaining the HT formula representation of these two programs:
Let us denote Rule 1 from Listing 3 as
$F$
(this rule is common to both programs). Let
$G_1$
denote Rule 2 from Listing 3, and
$G_2$
denote the constraint (3). Furthermore, let
$\mathcal{A}$
denote ordering sentences
\begin{align*} \forall X (hp(X) \rightarrow tp(X)) \qquad \text{and} \qquad \forall X_1 X_2 (hq(X_1, X_2) \rightarrow tq(X_1, X_2)). \end{align*}
The strong equivalence of these programs can be established by showing that
\begin{equation*}\mathcal{A} \rightarrow ( \gamma (\mu (\{F, G_1\})) \leftrightarrow \gamma (\mu (\{F, G_2\})) )\end{equation*}
is satisfied, in the sense of classical first-order logic, by all standardFootnote 3 interpretations (Fandinno and Lifschitz Reference Fandinno and Lifschitz2023b,Theorem 2). ANTHEM decomposes this task into four subproblems, each of which consists of verifying that one of the following implications is satisfied by all standard interpretations:
\begin{align*} (\mathcal{A} \wedge \gamma (\mu F) \wedge \gamma (\mu G_1)) &\rightarrow \gamma (\mu F), \qquad (\mathcal{A} \wedge \gamma (\mu F) \wedge \gamma (\mu G_1)) \rightarrow \gamma (\mu G_2),\\ (\mathcal{A} \wedge \gamma (\mu F) \wedge \gamma (\mu G_2)) &\rightarrow \gamma (\mu F), \qquad (\mathcal{A} \wedge \gamma (\mu F) \wedge \gamma (\mu G_2)) \rightarrow \gamma (\mu G_1). \end{align*}
ANTHEM checks that these implications (two of which are trivial) are entailed by a set of axioms describing standard interpretations using a classical ATP system, currently VAMPIRE, and answers that the two programs are strongly equivalent if it finds that all four implications are entailed by the axioms.
4.2 External equivalence
Strong equivalence can sometimes be too strong of a condition when we are comparing the behavior of two programs. Often, we are only interested in confirming that two programs have the same output when paired with the same input. This type of equivalence is called external equivalence (Fandinno et al. Reference Fandinno, Lifschitz, Gaggl, Martinez and Ortiz2023). External equivalence is defined with respect to a user guide, which defines a class of acceptable inputs to the programs, and specifies which predicates encode their output.
A user guide contains statements of three types: input declarations, output declarations, and assumptions about the inputs. An input declaration describes an input predicate or a placeholder (a symbolic constant i.e., given a value by the program’s input). Note that ANTHEM does not require a concrete valuation of placeholders – for instance, Listing 2 only specifies that a is an integer greater than 1. This user guide also specifies, via the declaration of prime/1 as the only output predicate, that only atoms in the stable model that contain prime/1 are considered when checking for external equivalence. We can verify that the program in Listing 1 is externally equivalent to the more efficient program in Listing 4 for any pair of integers
$(a,b)$
such that
$a \gt 1$
. If primes.ug is the file containing the user guide in Listing 2, ANTHEM can automatically prove the aforementioned claim.
Listing 4. A refactored primes program, primes.3.lp.
To achieve this, ANTHEM first builds the completion of the
$\tau ^*$
formula representation of each of the programs (Sections 3.1 and 3.2.2) and then produces a series of subtasks to verify using VAMPIRE. These subtasks are described by Fandinno et al. (Reference Fandinno, Lifschitz, Gaggl, Martinez and Ortiz2023) and a detailed example is given in Section 5.3. Note that verifying the preceding example is difficult for the current version of VAMPIRE without some human help (see Section 5). It is also worth mentioning that currently, ANTHEM can only automatically verify external equivalence for programs that are tight and lack private recursion (Fandinno et al. Reference Fandinno, Lifschitz, Gaggl, Martinez and Ortiz2023, Section 6). Note that strong equivalence verification does not suffer this restriction, and, in certain cases, the tightness limitation can be lifted (see Section 5).
4.3 Specification adherence
Thus far, we have discussed how ANTHEM can be used to establish that certain types of equivalences hold between two ASP programs. In this section, we show how ANTHEM can verify the adherence of an ASP program to a specification written in classical first-order logic. This workflow can be viewed as a special type of external equivalence checking, where instead of encoding our specification of desired behavior as an ASP program, we encode it directly in ANTHEM ’s control language. For example, we can validate that the program given in Listing 5 correctly solves the exact coverFootnote 4 problem by directly encoding the properties our program should possess as follows.
Listing 5. An encoding (cover.lp) solving the exact cover problem.
First, a solution to this problem is a collection of set identifiers in the range
$[1,n]$
:
Second, each element that occurs in the union of all sets must occur in the cover:
Finally, sets selected to be part of the cover cannot overlap:
Keep in mind that we need to restrict our input to sets identified by the range
$[1,n]$
:
We can verify Listing 5 against this specification with the following user guide:
using the command
This workflow tells us that cover.lp has the properties encoded by the specs and that our specification cover.spec completely defines the external behavior of the program in cover.lp with respect to this user guide. If we remove one of the specs from cover.spec, then the preceding command fails, since the specification is no longer a complete description of the program’s behavior. However, the following command succeeds.
This tells us that the program embodies the remaining properties of the specification.
More broadly, for any verification task, ANTHEM attempts to validate some form of equivalence. Thus, we can run the forward and backward directions of this equivalence proof separately if desired. In the case of external equivalence, we can frame our task as a proof of the equivalence between a program and a specification; our specification can be written as a logic program or as a collection of assumptions about the input and formulas annotated with the spec role.
5 ANTHEM in practice
One of the goals of this paper is to provide practical advice for using ANTHEM and demystify the interpretation of the results produced. Chances are your experience with ANTHEM will fall into one of three categories.
5.1 The good
This is the most straightforward case: ANTHEM returns a message like
For instance, invoking the command from Section 4.1 produces an output summarizing the two subproblems passed to VAMPIRE and their respective success statuses. Here, all subproblems in both the forward and backward directions of the equivalence proof ended with a “Status: Theorem” message. This means that the subproblem conjecture was successfully derived from the subproblem axioms. Since every subproblem was verified, the programs transitive.1.lp and transitive.2.lp are strongly equivalent.
5.2 The bad
There are certain types of problems that ANTHEM is not equipped to address. The most common such problem is the task of validating the external behavior of a non-tight program, which the current incarnation of ANTHEM refuses to attempt. One notable exception is the case of local tightness (Fandinno et al. Reference Fandinno, Lifschitz and Temple2024). Many non-tight programs are still locally tight, such as programs encoding planning problems in which the law of inertia introduces positive recursion. While tightness is a syntactic property of programs that is easily checked by ANTHEM, an effective procedure for checking local tightness has not been developed. If, however, a user has manually proven the local tightness of their program(s), ANTHEM’s tightness check can be bypassed, and verification safely completed, by adding the –bypass-tightness flag.
5.3 The ugly
When ANTHEM fails to verify a program, it is not a proof that the programs are not (strongly, externally) equivalent. It very well may be that the proof exists, but ANTHEM needs some help finding it. What can be done in these cases?
Option 1: Increase resource allocation. ANTHEM lets you increase the timeout -t for the backend ATP for each subproblem. You can also parallelize search by increasing the number of cores used by the ATP with the -m flag.
Option 2: Explore missing or malformed assumptions. If ANTHEM is hung up on a particular subproblem, consider the axiom set and conjecture. Is it clear that the conjecture follows from the axioms? Sometimes seemingly self-evident assumptions are missing – for a detailed example, see the “orphan” example by Fandinno et al. (Reference Fandinno, Lifschitz, Gaggl, Martinez and Ortiz2023).
Option 3: Write a proof outline. If VAMPIRE is unable to validate a subproblem in a reasonable amount of time (as is often the case for nontrivial tasks), the next step is to find a lemma that can be derived by VAMPIRE from the axioms without help and that is likely to facilitate achieving the goal when added to the list of axioms. Thus, for external equivalence tasks, ANTHEM lets users supply a proof outline consisting of annotated formulas that can play three roles: definitions, lemmas, and inductive lemmas. These are target language formulas augmented with instructions for how they should be used within a verification task. Their general form is
where role and formula are required, and direction indicates which direction of the equivalence proof the formula is used within. Such outlines can often be very effective.
Definitions are assumed to define the extent of a new predicate introduced for convenience within a proof outline. They have the form
where X is a tuple of variables, p is a fresh predicate symbol, and F is a formula with free variables X. A sequence of definitions is valid if any defined predicate
$p$
used within each
$F$
is defined previously in the sequence. For example, the annotated formula (
$D$
)
defines the integer square root (
$I$
) of an integer
$N$
. Definitions can be used in a proof similarly to assumptions as their purpose is to make writing lemmas easier.
Lemmas. ANTHEM interprets proof outlines in an intuitive way: as a series of intermediate claims to be checked en route to a final claim. Previously established results in this sequence are used as assumptions when checking the next claim. When ANTHEM is provided with a proof outline as part of an external equivalence verification task, it attempts to sequentially verify every (inductive) lemma. If successful, it treats the resulting set of formulas as assumptions during the verification task. For example, a proof outline consisting of
$D$
and the following two lemmas (
$L_1$
and
$L_2$
) is interpreted as an instruction to derive
$L_1$
from
$D$
and
$L_2$
from
$\{D, L_1\}$
.
Inductive lemmas have the general form
where n is an integer, X is a tuple of variables, N is an integer variable and F is a target language formula. Within a proof outline, an inductive lemma is interpreted as an instruction to prove two conjectures:
\begin{gather*} \forall X F(X,n) \qquad \text{ and } \qquad \forall X N ( N \geq n \wedge F(X,N) \rightarrow F(X,N+1) ). \end{gather*}
If both the first (the base case) and the second (the inductive step) conjectures are proven, then the original formula
\begin{gather*} \forall X N ( N \geq n \rightarrow F(X,N) ) \end{gather*}
is treated as an axiom in the remaining proof steps. For example,
$L_2$
is interpreted as an instruction to verify
\begin{gather*} \exists I sqrt(I,0) \qquad \text{ and } \qquad \forall N (N \geq 0 \wedge \exists I sqrt(I,N) \rightarrow \exists J sqrt(J,N+1)). \end{gather*}
We can verify the external equivalence of Listings 1 and 4 with respect to the user guide in Listing 2 with the proof outline primes.po, which extends
$\{D, L_1, L_2\}$
with the following lemmas,
$L_3$
and
$L_4$
:
Let us denote the assumption a > 0 from Listing 2 as
$A$
. Additionally, let us denote the completion of Rule 1 from Listing 1 as
$F$
, the completion of Rule 2 from Listing 1 as
$F'$
, the completion of rules 1 and 2 from Listing 4 as
$G$
, and the completion of Rule 3 from Listing 4 as
$G'$
. When the following command is invoked
ANTHEM verifies the proof outline as described above, then verifies the following subproblems in which the completed definitions of private predicates are treated as assumptions from which to derive the equivalence of the public predicates’ definitions:
\begin{align*} &\left ( A \wedge L_1 \wedge L_2 \wedge L_3 \wedge L_4 \wedge F(\mathbf{p}) \wedge G(\mathbf{q}) \wedge F'(\mathbf{p}) \right ) \rightarrow G'(\mathbf{q}),\\ &\left ( A \wedge L_1 \wedge L_2 \wedge L_3 \wedge L_4 \wedge F(\mathbf{p}) \wedge G(\mathbf{q}) \wedge G'(\mathbf{q}) \right ) \rightarrow F'(\mathbf{p}). \end{align*}
Here,
$\mathbf{p}$
is a list of fresh predicate symbols,
$\{composite/1\}$
, to replace the private predicates occurring in primes.1.lp. Similarly,
$\mathbf{q}$
replaces the private predicates occurring in primes.3.lp with predicate symbols that won’t conflict with
$\mathbf{p}$
:
$\{sqrtb/1, composite\_p/1\}$
.
A challenging example Fandinno et al. (Reference Fandinno, Lifschitz and Temple2024) provide two alternative solutions (Sections 1 and 5) to the frame problem, using different approaches to encoding the law of inertia. While these programs are not tight, they are locally tight, allowing us to safely bypass the tightness check. If we provide ANTHEM with the following proof outline
we can verify the external equivalence of the two frame programs. This example is remarkable due to the complexity of the programs (which use powerful modeling features to encode a realistic problem from the ASP literature), and the fact that we can prove external equivalence for arbitrary time horizons
$h \geq 0$
using a single inductive lemma.
Table 1. Tools supporting proof-based verification of ASP programs
6 Experimental analysis
This section compares the capabilities (Table 1) and performance (Table 2) of ANTHEM 2.0 against related systems, particularly its predecessors. As mentioned in the Introduction, tools from the ANTHEM family are oriented towards a different class of logic programs than SELP, DLPEQ, and CCT, which were designed for propositional SMODELS or DLV programs with disjunctive heads. As shown in Table 1, they do not support variables, double negation, or arithmetic. Hence, there cannot be a sensible runtime comparison between these systems and ANTHEM 2.0. Furthermore, they employ a different type of backend inference engine – the common theme of these systems is to convert a verification task into a satisfiability problem for some form of solver. SELP, DLPEQ, and CCT use SAT, ASP, and Quantified Boolean Formula (QBF) solvers, respectively. ANTHEM systems, on the other hand, use an automated theorem prover (ATP) as a backend.
Table 2. Comparing ANTHEM 2.0 against its predecessors
In addition to supporting several useful language features as shown in Table 1, ANTHEM 2.0 also permits users to verify multiple types of equivalence. For example, it supports specification adherence verification in the style of ANTHEM-1, implemented as a special case of external equivalence. This type of verification is unique – all other types in the table refer to a form of equivalence between logic programs. Interestingly, ANTHEM-P2P and ANTHEM 2.0, by virtue of their ability to verify external equivalence of logic programs, also support weak equivalence. Weak (or answer set) equivalence between programs
$\Pi _1$
and
$\Pi _2$
can be verified by comparing them under a user guide without placeholders, assumptions or input declarations, that contains every predicate in
$\Pi _1 \cup \Pi _2$
as an output predicate. Note that CCT supports a form of relativized uniform equivalence with projection similar to external equivalence when placeholders are forbidden, in addition to a generalized form of strong equivalence relativized to a propositional signature.
Recall that ANTHEM 2.0 was an effort to integrate, stabilize, and extend the capabilities of previous prototypes developed for one type of equivalence only. As such, there is at most one competitor to ANTHEM 2.0 for each problem in Table 2. The problems considered are a subset of the repository’s res/examples folder, excluding only trivial parsing tests. Times are given in seconds, the
$m$
parameter represents the number of cores allocated to VAMPIRE, and the “PO” column indicates if a proof outline was provided to aid in solving the problem within the 5-minute time limit. All experiments were conducted on Ubuntu 24.04.2 LTS, 13th Gen Intel(R) Core(TM) i7-1370P, 32 GB RAM.
These comparisons demonstrate that ANTHEM 2.0 is considerably more powerful than its predecessors when applied to non-trivial problems, both in terms of capabilities and performance. In particular, the new features of proof outlines (definitions and inductive lemmas) have enabled us to verify problems that previous systems could not address in a reasonable amount of time. Consider the challenging Frame problem discussed at the end of Section 5. While even ANTHEM 2.0 was initially unable to address this problem within the 5-minute timeout, the use of a proof outline with the new inductive lemma feature brought the runtime down to 7.88 s. Indeed, Division, Frame, and Primes (2v3) all rely on proof outlines with features specific to ANTHEM 2.0.
For certain trivial problems (Bounds, Successor, Transitive), ANTHEM-SE outperforms ANTHEM 2.0, although the differences for the Transitive problem are negligible. For the other two problems, this is likely due to a shortcut employed by ANTHEM-SE when it encounters positive programs. A positive rule is a basic rule or constraint whose body does not contain negation. For simple programs of this nature, the
$\gamma$
transformation can be omitted when checking strong equivalence (Lifschitz et al. Reference Lifschitz, Lühne, Schaub, Balduccini, Lierler and Woltran2019, Proposition 6).
7. Conclusions and future work
This paper provides an overview of the ANTHEM 2.0 system. We strongly encourage interested readers to also visit the ANTHEM repository, where a user manual and set of examples with expected outputs may be found. The systems developed in the ANTHEM project are unique within the landscape of (proof-based) ASP verification tools due to their support for programs with variables and integer arithmetic. ANTHEM 2.0 subsumes previous ANTHEM systems and provides powerful new features such as natural translation for strong equivalence tasks and enhanced proof outlines for external equivalence problems. Proof outlines, for instance, make previously unsolved problems such as the external equivalence of Listings 1 and 4 tractable. Additionally, the (optional) decoupling of the translation and verification steps may prove to be a useful tool for studying the relationship between ASP and other logical formalisms such as classical first-order logic.
This tool offers a stable foundation for future innovation. A number of improvements are already planned or in progress, including improved algorithms for simplifying formulas, proof outlines for strong equivalence tasks, employing alternative backend ATP systems, integration of natural translation into external equivalence verification, bypassing tightness restrictions with ordered completion and/or tightening, extending the supported language with conditional literals, supporting counting and/or unrestricted aggregates, and revising the definition of integer division for consistency with CLINGO (Fandinno and Lifschitz Reference Fandinno, Lifschitz, Lühne and Schaub2023a, Footnote 3). The long-term goal is to support the complete ABSTRACT GRINGO language within ANTHEM.
Acknowledgements
We are thankful to the anonymous reviewers for their valuable feedback. This research is partially supported by NSF CAREER award 2338635 and the research development program at the University of Nebraska Omaha. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation.
Open access
