1 Introduction
This paper continues the line of research aimed at investigating the relationship between logic programs and firstorder 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 covers^{1}^{1}1 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 firstorder 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 1to1 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
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 FirstOrder Theories
The translation Lifschitz et al. (2019) converts a program into a finite set of firstorder 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.
A 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 twosorted 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 firstorder 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 firstorder theory .
Recall that, for any firstorder sentence and any list of predicate symbols (other than equality), stands for the secondorder 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 manysorted 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 firstorder 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 ioprogram, 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 ioprogram 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 ioprogram 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 ioprograms if we agree to identify a program with the ioprogram (5) in which and are empty and is the set of all predicate symbols that occur in the rules of .
5.2 Semantics
A valuation for an ioprogram 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 ioprogram 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 iomodel of an ioprogram 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 iomodel of is .
It is clear that atoms in an iomodel do not contain private symbols. Furthermore, if is an iomodel 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 .
IOmodels of ioprograms also have a characterization in terms of firstorder 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 ioprograms 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 ioprogram 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 firstorder 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 iomodels that the future ioprogram 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 iomodel 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 firstorder theory. This is how anthem works.
6 Completion and Tightness
6.1 Completed Definitions
The definition of a predicate symbol in an ioprogram 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 secondorder formulas—the private symbols of are represented in them by predicate variables.
Let be an ioprogram 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 ioprogram 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 secondorder 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 iomodel of an ioprogram for an input , then the interpretation satisfies .
6.3 Tight Programs
The predicate dependency graph of an ioprogram 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 ioprogram is tight if its predicate dependency graph has no cycles consisting of positive edges.
Theorem 2.
For any tight ioprogram and any set of precomputed public atoms without placeholders, is an iomodel of for an input iff satisfies and .
This theorem shows that, in application to tight ioprograms, the semantics of specifications (Section 5.3) can be characterized in terms of completion: A tight ioprogram 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 ioprogram 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 firstorder reasoning.
6.4 Private Recursion
Recall that the completion of an ioprogram 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 ioprogram , 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 ioprogram 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 ioprogram 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 firstorder 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 ioprogram 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.^{2}^{2}2https://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 firstorder logic.
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).
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.^{3}^{3}3 When running vampire 4.4 with the options mode casc and cores 8 on a computer with an Intel Core i77700K 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 firstorder 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.
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).
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 lpfunctions, 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 firstorder 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, 45, 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, 45, 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, 56, 855–871.
 Kovács and Voronkov (2013) Kovács, L. and Voronkov, A. 2013. Firstorder 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 firstorder 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 translationbased 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 firstorder ASP and the logic FO(ID) through reducts. In Correct Reasoning: Essays on LogicBased 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 twosorted 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 INFstable 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 twosorted signature can be seen as onesorted if we do not assign sorts to variables. On the other hand, some onesorted terms and formulas cannot be viewed as terms or formulas over ; for instance, the onesorted term , where and are program variables, is not a term over . We will refer to terms, formulas, and theories over as twosorted. Onesorted interpretations are defined as usual in firstorder logic, with integer and program variables ranging over the same domain. Onesorted stable models and onesorted INFstable models are defined as stable models and INFstable models (see Section 4), respectively, but using onesorted interpretations rather than twosorted ones. We also say that two theories are onesortedequivalent if both theories have exactly the same onesorted models. The following is a special case of Theorem 5 in Truszczyński (2012) restricted to our onesorted language.
Proposition 1.
Let be a finite theory and
Comments
There are no comments yet.