Higher-Order MSL Horn Constraints: Jerome Jochems, Eddie Jones, Steven Ramsay

Higher-Order MSL Horn Constraints
JEROME JOCHEMS, University of Bristol, UK

EDDIE JONES, University of Bristol, UK
STEVEN RAMSAY, University of Bristol, UK
The monadic shallow linear (MSL) class is a decidable fragment of first-order Horn clauses that was discovered
and rediscovered around the turn of the century, with applications in static analysis and verification. We
propose a new class of higher-order Horn constraints which extend MSL to higher-order logic and develop
a resolution-based decision procedure. Higher-order MSL Horn constraints can quite naturally capture the
complex patterns of call and return that are possible in higher-order programs, which make them well suited
to higher-order program verification. In fact, we show that the higher-order MSL satisfiability problem and the
HORS model checking problem are interreducible, so that higher-order MSL can be seen as a constraint-based
approach to higher-order model checking. Finally, we describe an implementation of our decision procedure
and its application to verified socket programming.
CCS Concepts: • Theory of computation → Functional constructs; Program verification; Logic and
verification.
Additional Key Words and Phrases: higher-order program verification, constraint-based program analysis
ACM Reference Format:
Jerome Jochems, Eddie Jones, and Steven Ramsay. 2023. Higher-Order MSL Horn Constraints. Proc. ACM
Program. Lang. 7, POPL, Article 69 (January 2023), 31 pages. https://doi.org/10.1145/3571262
1 INTRODUCTION
Constraints of various kinds form the basis of many program analyses and type inference algo-
rithms. Specifying an analysis as a combination of generating and resolving constraints is very
appealing: as Aiken [1999] remarks in his overview paper, constraints help to separate specification
from implementation, they can yield natural specifications and their often rich theory (typically 69
independent from the problem at hand) can enable sophisticated optimisations that may not be
apparent if stating the analysis algorithm directly.
To realise these advantages, we want classes of constraints that can naturally express important
features of the problem domain, that draw upon a well-understood theory and yet have a decidable
satisfiability problem.
In this work we propose a new class of constraints that are designed to capture the complex,
higher-order behaviours of programs with first-class procedures. We develop a part of the theory
of these constraints and situate them in relation to other higher-order program analyses. Finally,
we obtain an efficient decision procedure and we describe an application of the constraints to
automatic verification of socket programming in a functional programming language.
Authors’ addresses: Jerome Jochems, Department of Computer Science, University of Bristol, Bristol, UK, jerome.jochems@
bristol.ac.uk; Eddie Jones, Department of Computer Science, University of Bristol, Bristol, UK, [email protected]; Steven
Ramsay, Department of Computer Science, University of Bristol, Bristol, UK, [email protected].
This work is licensed under a Creative Commons Attribution 4.0 International License.
© 2023 Copyright held by the owner/author(s).
2475-1421/2023/1-ART69
https://doi.org/10.1145/3571262
Proc. ACM Program. Lang., Vol. 7, No. POPL, Article 69. Publication date: January 2023.
69:2 Jerome Jochems, Eddie Jones, and Steven Ramsay
1.1 MSL Horn Constraints

Our constraints can be framed as an extension of the well-known Monadic Shallow Linear (MSL)
Horn constraints to higher-order logic. Like many natural ideas, MSL constraints were discovered
independently in two different communities. At CADE’99, Weidenbach [1999] proposed MSL Horn
constraints as a natural setting in which to “combine the benefits of the finite state analysis and
the inductive method”. He showed that satisfiability was decidable and described how this class of
constraints could be used in an automatic analysis of security protocols. Independently, at SAS’02,
Nielson et al. [2002] proposed the H 1 class of Horn constraints, and it was later observed by
[Goubault-Larrecq 2005] to be an equivalent reformulation of MSL. The H 1 class was originally
used for the control flow analysis of the Spi language, but has also been applied to e.g. the verification
of cryptosystems written in C.
MSL is the fragment of first-order Horn clauses obtained by restricting predicates to be monadic
and restricting the subject of positive literals to be shallow and linear – that is, the single argument
of a predicate in the head of a clause must be either a variable 𝑥 or a function symbol applied
to distinct variables: 𝑓 (𝑥 1, . . . , 𝑥𝑛 ). In practice, because we can view the function symbol 𝑓 as
constructing a tuple (𝑥 1, . . . , 𝑥𝑛 ), it is convenient to also allow non-monadic predicates, so long as
they are only applied to variables when used positively: 𝑃 (𝑥 1, . . . , 𝑥𝑛 ). With this concession, all of
the following are MSL Horn clauses (we omit the prefix of universal quantifiers in each case):
Zero(𝑥) ⇒ Leq(𝑥, 𝑧) Leq(s(𝑥), s(𝑦)) ⇒ Leq(𝑥, 𝑦) Leq(𝑥, 𝑦) ∧ Leq(𝑦, 𝑧) ⇒ Leq(𝑥, 𝑧)
Black(leaf) Black(branch(𝑥, 𝑑, 𝑧)) Black(𝑥) ∧ Black(𝑧) ⇒ Red(branch(𝑥, 𝑑, 𝑧))
M(sent(𝑦, b, pr(encr(tr(𝑦, 𝑥, tb(𝑧)), bt), encr(nb(𝑧), 𝑥)))) ∧ Sb(pr(𝑦, 𝑧)) ⇒ Bk(key(𝑥, 𝑦))
Note: there are no syntactical restrictions on the body of clauses. As can be seen in the last example,
which is taken from Weidenbach’s security protocol analysis, atoms in the body may contain terms
with arbitrary nesting.
Sets of MSL clauses were shown by Weidenbach to have decidable satisfiability. The procedure
is an instance of ordered resolution, with a carefully crafted ordering that guarantees terminating
saturation. Essentially the same procedure was rediscovered independently by Goubault-Larrecq
as he sought to construct a more standard procedure than Nielsen, Nielsen and Seidl’s original,
which was a bespoke kind of constraint normalisation.
In each case, the authors identify a key, solved form for constraints. Clauses in this solved form
have shape: 𝑄 1 (𝑦1 ) ∧ · · · ∧ 𝑄𝑘 (𝑦𝑘 ) ⇒ 𝑃 (𝑓 (𝑥 1, . . . , 𝑥𝑚 )) with {𝑦1, . . . , 𝑦𝑘 } ⊆ {𝑥 1, . . . , 𝑥𝑚 }. A set
of clauses of this form can straightforwardly be viewed as an alternating tree automaton and
so such clauses are called automaton clauses. Given as input a set of MSL Horn constraints C,
each of the above decision procedures can be viewed as constructing a set of automaton clauses
A equi-satisfiable with C; and since A is essentially a tree automaton, its satisfiability can be
effectively determined.
1.2 Contributions of this Paper

In this work, we propose three different higher-order extensions of MSL constraints: (i) the class
HOMSL(1) obtained by allowing predicates of higher types but maintaining the limitation of first-
order function symbols, (ii) the class MSL(𝜔) obtained by allowing function symbols of higher types
but maintaining the limitation of first-order (monadic) predicates and (iii) the class HOMSL(𝜔)
obtained by allowing both predicates and function symbols of higher type.
I. Reduction to Existential-Free MSL(𝜔). Our first contribution is to show that the satisfiability
problem for all of the above classes reduces to the satisfiability problem for a fragment of MSL(𝜔)
Higher-Order MSL Horn Constraints 69:3
– i.e. first-order predicates with higher-order function symbols – in which formulas contain no
existential quantification. We show that existential quantifiers are, in a sense, already definable
using higher-order predicates and that higher-order predicates in general can be represented as
higher-order functions, whose truth is internalised as a new first-order predicate.
II. Decidability of MSL(𝜔). Our second contribution is to give a resolution-based algorithm for
deciding the satisfiability problem of MSL(𝜔). A key difficulty in generalising the resolution-
based decision procedure for the first-order fragment is handling negative literals whose subject
is headed by a variable: 𝑃 (𝑥 𝑠 1 · · · 𝑠𝑛 ). Literals of this form simply cannot occur in the first-order
case, and allowing (higher-order) resolution on such literals creates clauses that violate one of the
cornerstones of the decidability result at first order, namely that clause heads are shallow.
We introduce a novel kind of higher-order resolution that avoids this phenomenon, but it neces-
sitates a significantly different notion of automaton formula (i.e. solved form), which nevertheless
specialises to the existing definition at first order. A simple type system for automaton clauses
ensures that the level of nesting and the binding structure of variables is in tight correspondence
with the type-theoretic order of the function symbols involved. Consequently, as in the first-order
case, there can be only finitely many automaton clauses associated with a given problem instance,
and this forms the backbone of the decidability proof.
III. Interreducibility of MSL(𝜔), HORS Model Checking, and Intersection (Refinement) Typability.
Although they look superficially complex, it is easy to see that our higher-order automaton clauses,
viewed as constraints, are in 1-1 correspondence with a simple kind of intersection types used in
higher-order model checking. Since it is known that this class of intersection types define regular
tree languages [Broadbent and Kobayashi 2013], the name automaton clauses is still justified. Our
third contribution is to use this correspondence to moreover give two problem reductions: (i) from
MSL(𝜔) satisfiability to HORS model checking and (ii) from intersection typeability to MSL(𝜔)
satisfiability. The reduction from HORS model checking to intersection typeability is already well
known [Kobayashi 2013], and thus completes the cycle. We obtain from these reductions that
MSL(𝜔) satisfiability is (𝑛 − 1)-EXPTIME hard for 𝑛 ≥ 2 (here 𝑛 refers to the type-theoretic order
of the function symbols). This is the class of problems that can be solved in time bounded by a
tower of exponentials of height-𝑛.
IV. Application to Verified Socket Programming. As proof of concept, we have implemented a
prototype of our decision procedure in Haskell and applied it to the higher-order verification
problem of socket usage in Haskell programs. Interestingly, our extraction of clauses from a given
Haskell program does not analyse the source code directly. Instead, the domain-specific language is
represented as a typeclass that can be instantiated with a specific “analysis” instance that extracts
a representation of the program to be passed to our decision procedure in addition to the usual
IO implementation. The principle advantage of this approach is that the source code need not be
present, making way for library functions to appear freely. Furthermore, it is easier to implement
and maintain, as source code need not be separately processed. As far as we are aware, this technique
is novel and could be fruitfully applied to other domains.
1.3 Wider Significance

In first-order automated program verification there is a consensus around first-order logic as
foundation, to the benefit of the field. On the one hand, ideas from first-order logic, such as
interpolants, the Horn fragment, abduction, resolution, and so on have found an important place in
automated verification. On the other, first-order logic provides a common vocabulary with which
to understand the automated verification landscape conceptually, and locate different technologies.
However, higher-order automated program verification comprises a disparate collection of

formalisms: refinement types [Rondon et al. 2008; Terauchi 2010; Unno and Kobayashi 2009; Vazou
et al. 2015, 2013; Zhu and Jagannathan 2013], higher-order grammars and automata [Hague et al.
2008; Kobayashi 2013; Kobayashi and Ong 2009; Ramsay et al. 2014; Salvati and Walukiewicz 2016],
higher-order fixpoint logic [Bruse et al. 2021; Kobayashi 2021; Viswanathan and Viswanathan 2004],
and many others. Moreover, the procedures involved are often bespoke and difficult to relate to
techniques that are standard in first-order verification.
This paper is part of a larger effort to establish an analogous foundation for higher-order
automated program verification based on higher-order logic [Cathcart Burn et al. 2017, 2021;
Jochems 2020; Ong and Wagner 2019]. We have shown that a standard technique from first-order
automated reasoning, namely saturation under resolution, is effective at higher order, and even
forms a decision procedure for the higher-order extension of MSL. Furthermore, in combination
with our correspondence between intersection types and higher-order automaton clauses, this sets
up a pattern for understanding type-based approaches to verification more generally.
Our interreducibility results allow us to situate higher-order model checking (also known as
HORS model checking) conceptually, within the HOL landscape. This is beneficial because HORS
model checking, although influential, is a set of techniques for solving a somewhat exotic problem.
The safety version of the problem asks to decide if the value tree determined by a certain kind of
higher-order grammar is accepted by a Büchi tree automaton with a trivial acceptance condition
[Kobayashi 2013]. Thanks to the results of this paper, this form of higher-order model checking can
be located more simply as “a group of decision procedures for the MSL fragment”. We hope this will
make this topic more accessible to the wider verification community, since monadic, shallow, and
linear restrictions are well understood even by non-experts on higher-order program verification.
Our results also make an interesting connection with work on constructive logic and logic
programming. Our higher-order automaton formulas are a special form of higher-order hereditary
Harrop clauses (HOHH), lying in the intersection of HOHH goal and definite formulas. The fact that
we have shown them to play an essential role in characterising satisfiability for this class of higher-
order Horn clauses sheds a novel light on the relationship between these two classes of formulas,
which have been instrumental in the work of Miller and his collaborators [Miller and Nadathur
2012; Miller et al. 1991]. Furthermore, our intersection type and higher-order automaton clause
correspondence suggests an alternative to the “Horn Clauses as Types” interpretation pioneered
by Fu, Komendantskaya, and coauthors [Farka 2020; Fu and Komendantskaya 2015, 2017; Fu et al.
2016]. Instead of identifying Horn clauses and types, resolution and proof term construction, our
work casts types as monadic predicates, represented as HOHH clauses with a single free variable,
and saturation-under-resolution as type inference.
1.4 Outline
The paper is structured as follows. In Section 2 we introduce higher-order MSL Horn constraints
and their proof system, and we give an example of their use in verifying lazy IO computations. In
Section 3 we reduce the provability problem for HOMSL(𝜔) to the same problem for existential-free
MSL(𝜔). In Section 4 we introduce higher-order automaton clauses and use them in deciding
satisfiability (via goal-formula entailment). In Section 5, we show that the MSL(𝜔) satisfiability
and HORS model checking are interreducible. In Section 6 we describe our implementation and its
application. Finally, in Section 7 we conclude with a description of related and future work. All
proofs are available in the long version of this paper [Jochems et al. 2022].
(Var) 𝑥 :𝜏 ∈ Δ (Cst) 𝑐 :𝛾 ∈ Σ (Pred) 𝑃 :𝜌 ∈Π

Δ⊢𝑥 :𝜏 Δ ⊢𝑐 :𝛾 Δ⊢𝑃 :𝜌
Δ ⊢ 𝑠 : 𝜏1 → 𝜏2 Δ ⊢ 𝑡 : 𝜏1 Δ⊢𝐺 :𝑜 Δ⊢𝐻 :𝑜
(True) (App) (And)
Δ ⊢ true : 𝑜 Δ ⊢ 𝑠 𝑡 : 𝜏2 Δ ⊢𝐺 ∧𝐻 :𝑜
Δ, 𝑥 : 𝜎 ⊢ 𝐺 : 𝑜 Δ, 𝑦:𝜎 ⊢ 𝐺 : 𝑜 Δ, 𝑦:𝜎 ⊢ 𝐴 : 𝑜
(Ex) 𝑥 ∉ dom(Δ) (Cl)
Δ ⊢ ∃𝑥:𝜎. 𝐺 : 𝑜 Δ ⊢ ∀𝑦:𝜎. 𝐺 ⇒ 𝐴
Fig. 1. Typing of terms, goals and clauses
2 HIGHER-ORDER MSL HORN FORMULAS

The logics we consider will make a type-level distinction between predicates and the subjects that
they classify.
Definition 2.1 (Syntax of types). We consider a subset of simply typed applicative terms. Starting
from the atomic type of individuals 𝜄 and the atomic type of propositions 𝑜, the types are given by:
(Constructor Types) 𝛾 F 𝜄 |𝜅 →𝛾 (Predicate Types) 𝜌 F 𝑜 |𝜎→𝜌
(Constructor Arg Types) 𝜅 F 𝛾 (Predicate Arg Types) 𝜎 F 𝜅|𝜌
We use 𝜏 as a metavariable for types in general (i.e. that may belong to any of the above classes).
Thus, the constructor types are just the simple types built over a single base type 𝜄, and the
predicate types are those simple types with an 𝑜 in tail position (i.e. that are ultimately constructing
a proposition) and whose arguments are either other predicates or constructors. The introduction
of the metavariable 𝜅 seems unmotivated, but we will later place restrictions on 𝜅 that differ from
those on 𝛾 more generally. We define the order of a type as follows:
ord(𝜄) = ord(𝑜) = 0 ord(𝜏1 → 𝜏2 ) = max(ord(𝜏1 ) + 1, ord(𝜏2 ))
After introducing terms below, we will say that the order of a typed term is the order of its type.
Definition 2.2 (Terms, Clauses and Formulas). In all that follows, we assume a finite signature Σ
of typed function symbols and a finite signature Π of typed predicate symbols. We use 𝑎, 𝑏, 𝑐 and
other lowercase letters from the beginning of the Roman alphabet to stand for function symbols
and 𝑃, 𝑄, 𝑅 and so on to stand for predicates. Function symbols have types of shape 𝛾 and predicate
symbols have type of shape 𝜌.
Terms. We assume a countably infinite set of variables. We use lowercase letters 𝑥, 𝑦, 𝑧 and so on
to stand for variables. A type context, typically Δ, is a finite, partial function from variables to types.
Then terms, typically 𝑠, 𝑡, 𝑢, are given by the following grammar:
(Term) 𝑠, 𝑡, 𝑢 F 𝑥 | 𝑐 | 𝑃 | 𝑠𝑡
We will only consider those terms that are well typed according to the system specified in Figure 1,
in which (Ex) instantiates one variable at a time for convenience.
Since we work in higher-order logic, the syntactic category of terms includes both objects that
we think of as predicates (which have type 𝜌) and those that we think of as strictly the subjects of
predicates (which have type 𝛾). To make the discussion easier, we will typically refer to terms of
the former type as predicates and terms of the latter type 𝛾 as trees, or tree constructors.
The depth of a symbol 𝑥, 𝑐 or 𝑃 is 0 and the depth of an application 𝑠 𝑡 is the maximum of the
depth of 𝑠 and the depth of 𝑡 with 1 added.
𝐷 ⊢𝐺 𝐷 ⊢𝐻 𝐷 ⊢ 𝐺 [𝑡/𝑥] 𝐷 ⊢ 𝐺 [𝑠/𝑦]
(T) (And) (Ex) (Res) (∀𝑦. 𝐺 ⇒𝐴) ∈ 𝐷
𝐷 ⊢ true 𝐷 ⊢𝐺 ∧𝐻 𝐷 ⊢ ∃𝑥 . 𝐺 𝐷 ⊢ 𝐴[𝑠/𝑦]
Fig. 2. Proof system for goal formulas
Formulas. The atomic formulas, typically 𝐴 and 𝐵, are just those terms of type 𝑜. We define the
goal formulas and definite formulas by mutual induction using the following grammar:
(Goal Formula) 𝐺, 𝐻 F 𝐴 | 𝐺 ∧ 𝐻 | ∃𝑥:𝜎. 𝐺 | true
(Definite Formula) 𝐶, 𝐷 F ∀𝑦:𝜎. 𝐺 ⇒ 𝑃 𝑦 | ∀𝑦:𝜎. 𝐺 ⇒ 𝑃 (𝑐 𝑦) | 𝐶 ∧ 𝐷 | true
Wherever possible we will omit the explicit type annotation on binders and we write FV(𝑋 ) to
denote the typed free variables of some term, clause or formula 𝑋 . We identify formulas up to
renaming of bound variables.
The first two alternatives of the syntactic class of definite formulas are the two kinds of definite
clause that we consider in this work. They differ in the shape of the head of the clause (𝑃 𝑦 vs 𝑃 (𝑐 𝑦)),
but in both cases the variables 𝑦 are required to be distinct from each other (i.e. the arguments are
shallow and linear). This is how we express the MSL restriction in our higher-order setting.
We will often think of definite formulas rather as sets of definite clauses (the conjuncts of the
formula), thus legitimising notation such as (∀𝑦. 𝐺 ⇒ 𝑃 𝑦) ∈ 𝐷, and this is greatly smoothed by
adopting the following conventions: we identify formulas up to the commutativity and associativity
of conjunction and the use of true as unit.
In the following, we will only consider those goal formulas and clauses that are well typed
according to the judgement defined inductively in Figure 1.
2.1 Proof System and Decision Problems

In this paper we will mostly work with respect to a certain proof system for judgements of the
form 𝐷 ⊢ 𝐺, that is: from a given set of definite clauses 𝐷 a given goal formula 𝐺 follows.
Definition 2.3 (Proof System). The rules defining the system are given in Figure 2, with [𝑠/𝑦]
denoting the substitution of 𝑠𝑖 for each 𝑦𝑖 in 𝑦, and [𝑡/𝑥] of 𝑡 for 𝑥. Substitution terms may be
higher order and are assumed to be well typed. Note that the substitution in (Res) may be vacuous.
Most of the proof rules are standard but note that (Res) is given its name because it simulates
(part of) the role of the resolution rule in clausal presentations of higher-order logic and we will
sometimes refer to this rule as performing a “resolution step”. We note that the mechanism by
which a given definite clause and a corresponding atomic formula interact in the (Res) rule is by
matching rather than unification, and the reason that this is possible is because we have an explicit
existential introduction rule (Ex).
The above remarks are substantiated by the following result which, leveraging results on higher-
order constrained Horn clauses due to Ong and Wagner [2019], shows that this system characterises
truth for this fragment of higher-order logic under the standard semantics. The result requires that
we assume (a) the predicate signature contains a universal relation Univ𝜌 for each type 𝜌 occurring
in 𝐷 or 𝐺, which is axiomatised by a corresponding universal clause (∀𝑦. true ⇒ Univ𝜌 𝑦) in 𝐷,
and (b) that every tree constructor type 𝛾 that occurs in 𝐷 or 𝐺 is inhabited by some closed term.
Clearly, both of these can be satisfied by suitable extensions of the signatures if they are not satisfied
already. We shall call signatures that satisfy these requirements adequate.
Theorem 2.4. Assuming adequate signatures, the proof system is sound and complete.
For this reason, we will develop most of our results with respect to the proof system and implicitly
adhere to the usual definition of the semantics of formulas.
As a corollary of the correspondence between the systems, we also obtain that higher-type
existentials do not add any power to the system, and so can be ignored:
Corollary 2.5. 𝐷 ⊢ ∃𝑥:𝜌. 𝐺 if, and only if, 𝐷 ⊢ 𝐺 [Univ𝜌 /𝑥]
The proof system is very straightforward to use since, apart from choosing which clause to apply
in a (Res) step, the rules are syntax directed according to the shape of the goal. An example of the
use of the proof system is given following the next subsection, in 2.3.
As usual in higher-order logic, we write 𝐷 |= 𝐺 to mean “𝐺 holds for every model of 𝐷”.
Decision Problems. Although we have been discussing satisfiability in the introduction, a con-
junction of Horn constraints 𝐷 ∧ (𝐺 ⇒ false) is satisfiable iff 𝐷 ̸ |= 𝐺. Hence, we can equivalently
consider the problem of deciding the entailment problem 𝐷 |= 𝐺, and this is more natural in our
setup. Moreover, due to completeness, we can equivalently consider the provability of 𝐷 ⊢ 𝐺. We
state all kinds of problems because we will prefer one or the other in reductions according to the
shape of yes-instances and the form of the input.
Definition 2.6 (Entailment, satisfiability, and provability problems). Given a definite formula 𝐷
and a goal formula 𝐺 over signatures Π and Σ, the entailment problem is to determine 𝐷 |= 𝐺, the
satisfiability problem is to determine 𝐷 ̸ |= 𝐺 and the provability problem is to determine 𝐷 ⊢ 𝐺.
2.2 Stratification by Type-Theoretic Order

In the forgoing subsection we have given a very liberal account of what it means to extend MSL to
higher types, but one can imagine at least two other possible definitions which are just as natural.
First, we may consider a higher-order extension in which tree constructors are allowed to be of
higher type, but predicates are not – in other words, as in first-order MSL, the subject of a predicate
is a term of type 𝜄, but now this term may be constructed internally using constants of higher type.
Second, we may consider a higher-order extension in which predicates are allowed to be higher
order, but tree constructors are not – in other words, as in first-order MSL, the terms of type 𝜄 are
essentially first order, but now predicates may take other predicates as arguments.
These two fragments and the unrestricted logic of the previous subsection arise naturally from
the following stratification according to type-theoretic order.
Definition 2.7 (Higher-order fragments). The family of fragments HOMSL(𝑛), for 𝑛 drawn from
N ∪ {𝜔 }, denotes the restriction of the logic of the previous subsection to tree constructor argument
types 𝜅 of order at most 𝑛 − 1. The family of fragments MSL(𝑛) additionally restricts predicate
argument types 𝜎 to 𝜄 only (i.e. all predicates are of type 𝜄 → 𝑜).
Here we regard 𝜔 − 1 as 𝜔 and an index of 0 as a prohibition on arguments (i.e. one may not
construct function types). Under this stratification, we can recognise the following fragments:
• MSL(0) is Datalog: predicates are first order and their subjects are (nullary) constants.
• MSL(1) is the first-order MSL fragment.
• MSL(𝜔) is the second of the two higher-order extensions described above: we have first-order
predicates whose subjects are trees constructed from an arbitrary higher-order signature.
• HOMSL(0) is higher-order Datalog, as studied by, e.g. Charalambidis et al. [2019].
• HOMSL(1) is the first of the two higher-order extensions described above: we have higher-
order predicates over trees defined using only first-order tree constructors.
• HOMSL(𝜔) is the full language described in the previous subsection.
The MSL(0) and MSL(1) fragments live within first-order Horn clauses and follow Miller and
Nadathur [2012]’s presentation thereof (as fohc), while our larger fragments fall within higher-order
Horn clauses (as hohc):
fohc
MSL(0) ⊆ MSL(1) ⊆ ... ⊆ MSL(𝜔)
⊆
⊆
HOMSL(0) ⊆ HOMSL(1) ⊆ ... ⊆ HOMSL(𝜔)
hohc
2.3 Example: Constraints for Lazy IO

Our motivation is to use higher-order constraints to specify certain higher-order program verifi-
cation problems, and especially the verification of safety properties for functional programs. We
describe a general approach to using higher-order MSL constraints for verified socket programming
in Section 6, but let us here consider a different example: verifying the correctness of a lazy IO
computation. Consider the following Haskell expression, which is featured on the Haskell.org wiki
as a prototypical example of a mistake due to improper use of lazy IO for any input [Haskell.org
2013]. The expression throws a runtime exception for attempting to read from a closed file handle.
1 do contents ← withFile " test . txt " ReadMode hGetContents
2 putStrLn contents
This code reads the file named “test.txt” (line 1) and prints the contents to stdout (line 2).
The problem comes from the interaction between the lines. The reading of the file is done
using the primitive hGetContents, which returns the list of characters read from a handle lazily1 .
The hGetContents action is wrapped in the withFile combinator, which brackets the execution of
hGetContents between a call to open the handle and a call to close it again. Hence, at the point at
which the contents of the file are demanded, in line 2, the file handle has already been closed as a
result of leaving withFile, and forcing the lazy list of characters results in attempting to read from
this closed handle.
An abstraction of the behaviour of this expression, and the primitives and combinators contained
therein, can be expressed as a set of higher-order MSL clauses shown in Figure 3. A systematic
approach to verifying lazy IO is not a contribution of this work, so it is not essential to understand
the way in which these clauses model the situation. However, it is worth looking at the encoding in
some detail, since we will use it as a kind of running example. Note that [] and : are the usual Haskell
nullary and binary list constructors that denote the empty list and list composition, respectively.
The clauses effectively model a version of the above expression in which both global state (the
status of the file handle) and control flow (lazy evaluation) are represented explicitly by threading
a state parameter ℎ and passing continuations 𝑘 respectively. In addition to the various functions
that appear in the source code, but which now expect an additional pair of arguments ℎ and 𝑘,
there are two constants o and c, representing the two possible states (open and closed – recall that
we omit semi-closed for simplicity) of the handle, and four predicates V, Ex, Open and Closed.
The idea is that the predicate V (for ‘V’iolation) is true of its argument 𝑠 just if 𝑠 represents an
expression that will attempt to read from a closed file handle.
The goal V(withFile "test.txt" hGetContents c (act2 id)) represents the verification problem:
does the given expression crash with a closed file-handle violation? The idea of the representation is
1 In
fact the handle is put into an intermediate semi-closed state, but it is not important to this example so, in the interests of
simplicity, we will not model it in what follows.
𝑝 [] ⇒ Ex 𝑝 (1) Closed(ℎ) ⇒ V(read ℎ 𝑘) (7)

∃𝑦. 𝑝 (𝑦:read) ⇒ Ex 𝑝 (2) Open(ℎ) ∧ Ex (Pred ℎ 𝑘) ⇒ V(read ℎ 𝑘) (8)
V(𝑥) ⇒ V(id 𝑥) (3) V(𝑘 ())) ⇒ V(putCont 𝑘 𝑦 ℎ) (9)
V(𝑘 𝑥 ℎ) ⇒ Pred ℎ 𝑘 𝑥 (4) V(𝑥 ℎ (putCont 𝑘)) ⇒ V(putStrLn 𝑥 ℎ 𝑘) (10)
V(𝑘 o) ⇒ V(open ℎ 𝑘) (5) V(open ℎ (withFile1 𝑓 𝑘)) ⇒ V(withFile 𝑥 𝑚 𝑓 ℎ 𝑘) (11)
V(𝑘 c) ⇒ V(close ℎ 𝑘) (6) V(𝑓 ℎ 0 (withFile2 𝑘)) ⇒ V(withFile1 𝑓 𝑘 ℎ 0 ) (12)
V(close ℎ 1 (withFile3 𝑦 𝑘)) ⇒ V(withFile2 𝑘 ℎ 1 𝑦) (13)
V(𝑘 𝑦 ℎ 2 ) ⇒ V(withFile3 𝑦 𝑘 ℎ 2 ) (14)
Open(ℎ) ∧ V(𝑘 o read) ⇒ V(hGetContents ℎ 𝑘) (15)
V(putStrLn 𝑥 ℎ 3 id) ⇒ V(act2 𝑥 ℎ 3 ) (16)
true ⇒ Open(o) (17)
true ⇒ Closed(c) (18)
Fig. 3. Clauses corresponding to the verification of Example 2.3
(18)
Closed(c)
(7)
V(read c (putCont id))
(10)
V(putStrLn read c id)
(16)
V(act2 read c)
(14)
V(withFile3 read act2 c)
(6)
V(close o (withFile3 read act2 ))
(17) (13)
Open(o) V(withFile2 act2 o read)
Open(o) ∧ V(withFile2 act2 o read)
(15)
V(hGetContents o (withFile2 act2 ))
(12)
V(withFile1 hGetContents act2 o)
(5)
V(open c (withFile1 hGetContents))
(11)
V(withFile “test.txt” ReadMode hGetContents c act2 )
Fig. 4. Proof in the environment given by Figure 3
as follows. Given that we think of every function as taking a file handle and a continuation, we can
rephrase the expression as: withFile "test.txt" hGetContents c (𝜆𝑥 ℎ 3 . putStrLn 𝑥 ℎ 3 (𝜆𝑦. 𝑦))
This captures via continuation passing style that evaluation must proceed by executing the expres-
sion withFile "test.txt" hGetContents in the initially closed handle state and with continuation
𝜆𝑥 ℎ 3 . putStrLn 𝑥 ℎ 3 𝑘. This continuation takes the suspended lazy stream 𝑥 that is output by
hGetContents and the state of the handle ℎ 3 on exit from withFile, and attempts to print it to
stdout before continuing with the remainder of the program, which just returns whichever value is
output by putStrLn (which is just unit). However, since we don’t allow for 𝜆-abstractions in our
constraints, we give a 𝜆-lifted version of the above, with the innermost abstraction given instead
by id and the outer one given by act2 .
PQ 𝑥 ⇒S𝑥 T(p q 𝑥) ⇒ T(s 𝑥) R(a c)

R𝑦 ∧𝑥 𝑦 ⇒ P𝑥 𝑦 T(r 𝑦) ∧ T(𝑥 𝑦) ⇒ T(p 𝑥 𝑦) T(r (a c))
R 𝑥 ⇒ Q (a 𝑥) Q (𝑧) ⇒ T(q 𝑧) R(a (a c)) Q (a (a c))
true ⇒ R (a 𝑥) R(𝑧) ⇒ T(r 𝑧) T(r (a (a c))) ∧ T(q (a (a c)))
T(r 𝑥) ⇒ Q (a 𝑥) T(p q (a (a c)))
true ⇒ R(a 𝑥) T(s (a (a c)))
Fig. 5. Example of clauses (left) and their transform (center) and a proof (right)
Similarly, clauses (11)–(14) model the bracketing behaviour of withFile described above. An
application of withFile to a filename 𝑥 and an action on handle 𝑓 will cause a violation (when
started in a state in which the handle is ℎ and the remaining program to compute is 𝑘), whenever
open ℎ (𝜆ℎ 0 . 𝑓 ℎ 0 (𝜆𝑦 ℎ 1 . close ℎ 1 (𝜆ℎ 2 . 𝑘 𝑦 ℎ 2 ))) does. That is, calling open (with the same state ℎ)
to open the (implicit) file, then continuing by running the action 𝑓 , then continuing by calling close
and then finally continuing by executing the remainder of the program 𝑘 (supplying the output 𝑦
of the action 𝑓 ). The abstractions are lifted to, from left to right, withFile1 , withFile2 , and withFile3 .
Clauses (1) and (2) constrain Ex to act like a specialised kind of (higher-order) existential quantifier.
Ex takes a predicate 𝑝 as input and holds whenever there is some list, of a certain form, that satisfies 𝑝.
The form of the list models the thunking behaviour of the lazy stream resulting from hGetContents
– in particular the fact that the tail of the list comprises another call to read.
A proof of V(withFile "test.txt" hGetContents c (act2 id)), witnessing the fact that the ex-
pression does cause a violation, can be seen in Figure 4. Here, each use of (Res) is annotated by the
number of the clause as given in Figure 3.
3 FROM HOMSL(𝜔) TO EXISTENTIAL-FREE MSL(𝜔)

The full HOMSL(𝜔) fragment is a remarkably expressive language with higher-order constructors,
predicates, and existentials, allowing a wide range of higher-order verification problems to be
expressed in a language that closely matches a functional source program.
In this section, we show that some of that power is illusory: existential quantification is definable
using higher-order predicates (Theorem 3.2) and higher-order predicates are, in a sense, definable
already using higher-order function symbols (Theorem 3.1). Hence, we are able to reduce the
solvability problem from HOMSL(𝜔) to the solvability problem in existential-free MSL(𝜔). These
reductions are extremely helpful for developing the rest of the results in the paper.
3.1 Elimination of Higher-Order Predicates

The idea of the first reduction is to simulate higher-order predicates using higher-order function
symbols and a new, first-order “truth” predicate T : 𝜄 → 𝑜. Consider the set of HOMSL(𝜔) clauses
over predicates P : (𝜄 → 𝑜) → 𝜄 → 𝑜, Q : 𝜄 → 𝑜, R : 𝜄 → 𝑜, and S : 𝜄 → 𝑜, and function symbols
a : 𝜄 → 𝜄 and c : 𝜄 that is shown on the left of Figure 5. The goal S(a (a c)) is provable from these
clauses.
We will represent each of the predicates P, Q, R, and S by new function symbols p : (𝜄 → 𝜄) →
𝜄 → 𝜄, q : 𝜄 → 𝜄, r : 𝜄 → 𝜄, and s : 𝜄 → 𝜄 respectively. Since we have exchanged 𝑜 everywhere in
these types for 𝜄, combinations that were possible involving P, Q, and R are still possible using
their representatives, just with a different type. For example, P Q 𝑥 in the body of the first clause
can be represented as p q 𝑥, but note that this is a term of type 𝜄 so, in a sense, we have lost the
notion of when the proposition is true.
To recover truth, we install a new predicate T and formulate the set of MSL(𝜔) clauses shown
in the center of Figure 5. Thus T(𝑡) is true just if the proposition represented by the tree 𝑡 is true
(according to the representation scheme above). When 𝑡 is a first-order predicate application, then
its truth may depend on pattern matching in clause heads, and so truth is deferred to the original
predicate (e.g. in the third and fourth clauses). For example, we can derive the goal T(s (a (a c))),
which encodes the higher-order goal S(a (a c)), as shown on the right of Figure 5.
Theorem 3.1. Provability in HOMSL(𝜔) reduces to provability in MSL(𝜔).
Thanks to Corollary 2.5, we assume WLOG that 𝐷 and 𝐺 contain no existentials of type 𝜌.
First, from a given HOMSL(𝜔) constructor signature Σ and predicate signature Π, we construct
MSL(𝜔) signatures Σ# and Π# . Let us write 𝐷 ⊢𝜔 𝐺 to distinguish proof in the former and 𝐷 ⊢1 𝐺
in the latter. Then we construct a section (| − |) that maps formulas of the former into formulas of
the latter in such a way that 𝐷 ⊢𝜔 𝐺 iff (|𝐷 |) ⊢1 (|𝐺 |) .
The MSL(𝜔) Signature. Let Π 1 be the subsignature consisting only of the first-order monadic
predicates from Π. We start by transforming HOMSL(𝜔) types 𝜏 to MSL(𝜔) types (|𝜏 |) .
(|𝜄|) ≔ 𝜄 (|𝑜 |) ≔ 𝜄 (|𝜎 → 𝜌 |) ≔ (|𝜎 |) → (|𝜌 |)
We build MSL(𝜔) signatures and Σ# Π#
by introducing one additional first-order monadic predicate
symbol T to denote “truth”, and a new tree constructor 𝑝 # for each predicate symbol 𝑃 ∈ Π:
Σ# ≔ {𝑝 # : (|𝜌 |) | 𝑃 : 𝜌 ∈ Π} ∪ Σ Π # ≔ {T : 𝜄 → 𝑜 } ∪ Π1
The Term Transformation. Then define (|𝑡 |) by:
(|𝑥 |) ≔ 𝑥 (|𝑐 |) ≔ 𝑐 (|𝑃 |) ≔ 𝑝 # (|𝑠 𝑡 |) ≔ (|𝑠 |) (|𝑡 |)
By some abuse we write (|𝑠 |) to denote the pointwise transformation of a vector of terms 𝑠. We
extend this to goal formulas (|𝐺 |) by:
(|true|) ≔ true (|𝐴|) ≔ T ((|𝐴|) ) (|𝐺 ∧ 𝐻 |) ≔ (|𝐺 |) ∧ (|𝐻 |) (|∃𝑥 . 𝐺 |) ≔ ∃𝑥 . (|𝐺 |)
where, by some abuse, we refer to the term-level transformation on the right-hand side of the
second equation. We extend to definite formulas (|𝐶 |) by:
(|true|) ≔ true
(|𝐶 ∧ 𝐷 |) ≔ (|𝐶 |) ∧ (|𝐷 |)
(|∀𝑦. 𝐺 ⇒ 𝑃 𝑦|) ≔ ∀𝑦. (|𝐺 |) ⇒ T (𝑝 # 𝑦)
(|∀𝑦. 𝐺 ⇒ 𝑃 (𝑐 𝑦)|) ≔ (∀𝑦. (|𝐺 |) ⇒ 𝑃 (𝑐 𝑦)) ∧ (∀𝑧. 𝑃 𝑧 ⇒ T (𝑝 # 𝑧))
We call the second conjunct of the last case of this definition the reflection clause. Note that the
form of head in this case implies that 𝑃 : 𝜄 → 𝑜 in Π. There is some obvious redundancy in that the
image of the transformation will typically contain many copies of the same reflection clause, but
this could be easily avoided if considered undesirable.
Finally, 𝐷 ⊢ 𝐺 iff (|𝐷 |) ⊢ (|𝐺 |) completes the reduction from Theorem 3.1.
3.2 Elimination of Existentials

The completeness of our proof system shows (as is usual for Horn logics) that our fragment has the
existential witness property, that is: 𝐷 |= ∃𝑥 . 𝐺 iff 𝐷 |= 𝐺 [𝑡/𝑥] for some term 𝑡. Consequently, we
can simulate existential quantifiers of tree constructor types using higher-order predicates. We
introduce a family of new predicate symbols ∃𝛾 indexed by 𝛾 and constrain them so that they hold
of a given predicate 𝑝 on 𝛾 whenever 𝑝 holds for some term 𝑡.
For example, an existential quantifier ∃𝜄 : (𝜄 → 𝑜) → 𝑜 on natural numbers, constructed using
successor s : 𝜄 → 𝜄 and zero z : 𝜄, can be defined by the two clauses:
∀𝑝:𝜄 → 𝑜. 𝑝 z ⇒ ∃𝜄 𝑝 ∀𝑝:𝜄 → 𝑜. ∃𝜄 (𝜆𝑥 . 𝑝 (s 𝑥)) ⇒ ∃𝜄 𝑝
However, since we do without 𝜆-abstraction in our setting, we develop a version of the above with
a kind of built-in lambda-lifting in which a predicate Λ𝛾,𝐺 models the 𝜆-abstraction 𝜆𝑥 : 𝛾 . 𝐺. Thus,
an atom ∃𝜄 Λ𝜄,𝐺 will represent the goal formula ∃𝑥 : 𝜄. 𝐺.
Theorem 3.2. Provability in MSL(𝜔) reduces to provability in existential-free MSL(𝜔).
Because the elimination of higher-order predicates does not introduce existentials (Theorem 3.1),
it suffices to reduce provability in MSL(𝜔) to provability in existential-free HOMSL(𝜔); given MSL(𝜔)
definite formula 𝐷 and goal formula 𝐺 over constructor signature Σ and predicate signature Π, we
construct a HOMSL(𝜔) definite formula 𝐷 and goal formula 𝐺 over constructor signature Σ
and predicate signature Π such that 𝐷 ⊢ 𝐺 if, and only if, 𝐷 ⊢ 𝐺 . Thanks to Corollary 2.5, we
assume WLOG that 𝐷 and 𝐺 contain no existentials of type 𝜌.
The Existential-Free HOMSL(𝜔) Signature. From a given MSL(𝜔) constructor signature Σ and
predicate signature Π, we construct HOMSL(𝜔) signatures Σ := Σ and Π .
Let sorts ∃ (𝐷 ∧𝐺) contain the sorts of existential variables appearing in 𝐷 ∧𝐺 and the arguments
of any constructor from Σ. Furthermore, we define goals ∃ (𝐷 ∧ 𝐺) as all goal formulas 𝐺 ′ such that
∃𝑥 . 𝐺 ′ appears in 𝐷 or 𝐺. For the purpose of the definition, we assume that there is some fixed
ordering on variables. We then define an extended predicate signature Π as follows:
Π := Π ∪ {∃𝛾 : (𝛾 → 𝑜) → 𝑜 | 𝛾 ∈ sorts ∃ (𝐷 ∧ 𝐺)}
∪ {Comp𝑖,𝑛
𝑓
: (𝛾 → 𝑜) → 𝛾 1 → · · · → 𝛾𝑖 → 𝑜 | 𝑓 : 𝛾 1 → · · · → 𝛾𝑛 → 𝛾 ∈ Σ, 0 ≤ 𝑖 ≤ 𝑛}
∪ {Λ𝛾, 𝐻 : 𝛾 1 → · · · → 𝛾𝑘 → 𝛾 → 𝑜 | 𝛾 ∈ Γ, 𝐻 ∈ goals ∃ (𝐷 ∧ 𝐺), FV(𝐻 ) \ {𝑥 } = {𝑥 1, . . . , 𝑥𝑘 }}
where Comp0,𝑛
𝑓
: (𝛾 → 𝑜) → 𝑜, and, in the final summand, we require each 𝑥𝑖 : 𝛾𝑖 . Intuitively,
Comp𝑖,𝑛 𝑓
denotes an eventual application of constructor 𝑓 to 𝑛 arguments, 𝑛 being at most the arity
of 𝑓 , with 𝑖 ≤ 𝑛 arguments already provided.
Existential-Free Goals. We map an MSL(𝜔) goal formula 𝐺 to an existential-free HOMSL(𝜔)
counterpart H𝐺I:
HtrueI := true H𝐴I := 𝐴 H𝐺 ∧ 𝐻 I := H𝐺I ∧ H𝐻 I H∃𝑥 : 𝛾 . 𝐺I := ∃𝛾 (Λ𝛾, 𝐺 𝑥 1 · · · 𝑥𝑘 )
where, in the last clause, FV(𝐺) \ {𝑥 } = {𝑥 1, . . . , 𝑥𝑘 }, as sequenced by the assumed order.
Existential-Free Definite Formulas. We map an MSL(𝜔) definite formula 𝐶 to an existential-free
HOMSL(𝜔) definite formula H𝐶I over (Σ, Π ):
HtrueI := true H𝐶 ∧ 𝐷I := H𝐶I ∧ H𝐷I H∀𝑦. 𝐺 ⇒ 𝑃 (𝑐 𝑦)I := (∀𝑦. H𝐺I ⇒ 𝑃 (𝑐 𝑦))
The Equi-Provable Existential-Free HOMSL(𝜔) Instance. For any MSL(𝜔) definite formula 𝐷 and
goal formula 𝐺, we define an equi-provable existential-free HOMSL(𝜔) instance with definite
formula 𝐷 and goal formula 𝐺 := H𝐺I 2 .
2 the clause head is Comp0,𝑛 𝑣 when 𝑖 = 0

𝑓
n o
𝐷 := Comp0,𝑛
𝑓
𝑣 ⇒ ∃𝛾 𝑣 𝑓 : 𝛾 1 → · · · → 𝛾 𝑛 → 𝛾 ∈ Σ, ∃ 𝛾 ∈ Π
n o
∪ 𝑣 (𝑓 𝑥 1 · · · 𝑥𝑛 ) ⇒ Comp𝑛,𝑛 𝑓
𝑣 𝑥 1 · · · 𝑥 𝑛 𝑓 : 𝛾 1 → · · · → 𝛾 𝑛 → 𝛾 ∈ Σ

𝑖+1,𝑛 𝑖,𝑛 𝑓 : 𝛾 1 → · · · → 𝛾𝑛 → 𝛾 ∈ Σ,
∪ ∃𝛾𝑖+1 (Comp 𝑓 𝑣 𝑥 1 · · · 𝑥𝑖 ) ⇒ Comp 𝑓 𝑣 𝑥 1 · · · 𝑥𝑖
0≤𝑖 <𝑛

∪ H𝐻 I ⇒ Λ𝛾, 𝐻 𝑥 1 · · · 𝑥𝑘 𝑥 𝛾 ∈ sorts ∃ (𝐷 ∧ 𝐺), 𝐻 ∈ goals ∃ (𝐷 ∧ 𝐺) ∪ H𝐷I
Partial instantiation of existential variables is key
to eliminating them. After all, there may be count-
𝑃 (𝑔 𝑎 𝑓 𝑏) ∧ 𝑄 (ℎ (𝑔 𝑎 𝑓 ))
ably many instantiations but only finitely many
clauses. To this end, predicates Comp𝑖,𝑛 act as de- Λ𝜄→𝜄,𝑃 (𝑥 𝑏)∧𝑄 (ℎ 𝑥) (𝑔 𝑎 𝑓 )
𝑓
layed applications of constructor 𝑓 that come into Comp𝑔2,2 (Λ𝜄→𝜄,𝑃 (𝑥 𝑏)∧𝑄 (ℎ 𝑥) ) 𝑎 𝑓
effect when all 𝑛 expected arguments to 𝑓 are fully
Comp0,0 (Comp𝑔2,2 (Λ𝜄→𝜄,𝑃 (𝑥 𝑏)∧𝑄 (ℎ 𝑥) ) 𝑎)
instantiated (when 𝑖 = 𝑛 and the clause headed by 𝑓
Comp𝑛,𝑛 𝑓
applies). ∃𝜄→𝜄 (Comp𝑔2,2 (Λ𝜄→𝜄,𝑃 (𝑥 𝑏)∧𝑄 (ℎ 𝑥) ) 𝑎)
For example, since 𝑔 : 𝜄 → (𝜄 → 𝜄) → 𝜄 → 𝜄 Comp𝑔1,2 (Λ𝜄→𝜄,𝑃 (𝑥 𝑏)∧𝑄 (ℎ 𝑥) ) 𝑎
has tail type 𝜄 → 𝜄 when given two arguments, we
may instantiate 𝑥 : 𝜄 → 𝜄 in ∃𝑥 . 𝑃 (𝑥 𝑏) ∧ 𝑄 (ℎ 𝑥) Comp𝑎0 (Comp𝑔1,2 (Λ𝜄→𝜄,𝑃 (𝑥 𝑏)∧𝑄 (ℎ 𝑥) ))
with 𝑔 𝑎 𝑓 (for 𝑎 : 𝜄 and 𝑓 : 𝜄 → 𝜄), resulting in the ∃𝜄 (Comp𝑔1,2 (Λ𝜄→𝜄,𝑃 (𝑥 𝑏)∧𝑄 (ℎ 𝑥) ))
existential-free proof in Figure 6.
It follows that, for goal formulas 𝐺 that are subex- Comp𝑔0,2 (Λ𝜄→𝜄,𝑃 (𝑥 𝑏)∧𝑄 (ℎ 𝑥) )
pressions of the given instance, 𝐷 ⊢ 𝐺 iff 𝐷 ⊢ 𝐺 . ∃𝜄→𝜄 (Λ𝜄→𝜄,𝑃 (𝑥 𝑏)∧𝑄 (ℎ 𝑥) )
Provability of the latter reduces to provability of
an existential-free MSL(𝜔) instance via the elim-
Fig. 6. Example existential-free proof
ination of higher-order predicates (Theorem 3.1),
which completes the reduction from Theorem 3.2.
4 HIGHER-ORDER AUTOMATON CLAUSES AND THE DECISION PROCEDURE

Consider MSL(𝜔) Δ ⊢ 𝐷 and Δ ⊢ 𝐺 over constructor signature Σ and predicate signature Π. We aim
to decide 𝐷 ⊨ 𝐺 by rewriting clauses to a solved form we call (higher-order) automaton formulas,
after their first-order counterparts in Goubault-Larrecq [2002].
4.1 Higher-Order Resolution

In Weidenbach’s original work on MSL and Goubault-Larrecq’s later work on H 1 [Goubault-
Larrecq 2005; Weidenbach 1999], satisfiability is decided by a form of ordered resolution: the given
set of MSL clauses is saturated under the ordered resolution rule and satisfiability is determined
according to the presence or absence of the empty clause.
There is a higher-order analogue of the resolution rule which also forms the core of a refutationally
complete calculus for higher-order (constrained) Horn clauses [Ong and Wagner 2019]:
𝐺 ∧ 𝑅 𝑠 ⇒ 𝐴 𝐺′ ⇒ 𝑅 𝑦
(HO-Resolution)
𝐺 ∧ 𝐺 ′ [𝑠/𝑦] ⇒ 𝐴
This higher-order rule has exactly the same structure as the standard first-order rule (for Horn
clauses). However, as we shall describe below, this form of resolution on its own does not lend
itself to a decision procedure for MSL(𝜔).
In the first-order case, the key to ensuring termination of saturation under resolution is to identify
a certain kind of solved form of constraints, which are called automaton. Such clauses have shape:
𝑄 1 (𝑥 𝜋 (1) ) ∧ · · · ∧ 𝑄𝑘 (𝑥 𝜋 (𝑘) ) ⇒ 𝑃 (𝑓 (𝑥 1, . . . , 𝑥𝑚 )) with 1 ≤ 𝜋 (𝑖) ≤ 𝑚 for all 𝑖. As remarked in the
introduction, such formulas are nothing but a clausal representation of alternating tree automata,
but for our purposes, there are two features to take note of: (a) they have a depth-1 head and each
atom in the body of the clause is depth 0, and (b) there are no existentially quantified variables
(variables that occur in the body but not in the head).
The ordering of the first-order resolution calculus is carefully crafted to ensure that the side
premise of each resolution inference is automaton. It is easy to see that a resolution inference
between an arbitrary MSL clause and an automaton clause will produce an MSL clause that is
strictly closer to automaton form, whenever the selected negative literal has depth at least 13 :
𝐺 ∧ 𝑃 (𝑓 (𝑡 1, . . . , 𝑡𝑛 )) ⇒ 𝐴 𝑄 1 (𝑥 𝜋 (1) ) ∧ · · · ∧ 𝑄𝑘 (𝑥 𝜋 (𝑘) ) ⇒ 𝑃 (𝑓 (𝑥 1, . . . , 𝑥𝑚 ))
𝐺 ∧ 𝑄 1 (𝑡𝜋 (1) ) ∧ · · · ∧ 𝑄𝑘 (𝑡𝜋 (𝑘) ) ⇒ 𝐴
Since the body of an automaton clauses is required to contain only atoms with depth 0, we can
think of the clause in the conclusion as closer to automaton form than the main premise (on the
left-hand side) since the new atoms 𝑄𝑖 (𝑡𝜋 (𝑖) ) in the body replace an atom 𝑃 (𝑓 (𝑡 1, . . . , 𝑡𝑛 )) of strictly
greater depth.
This is also the case for higher-order clauses in MSL(𝜔) whenever the selected negative literal is
headed by a function symbol. However, in higher-order clauses, the selected negative literal may
be headed by a variable, and this spells trouble. Consider, for example, the following resolution
inference. Recall that function application is conventionally left associative, so ℎ 𝑦1 𝑦2 = (ℎ 𝑦1 ) 𝑦2 .
P(𝑥 1 (f a 𝑥 2 )) ⇒ Q (g 𝑥 1 𝑥 2 ) R(𝑦2 ) ∧ S(𝑦2 ) ⇒ P(h 𝑦1 𝑦2 )
R(f a 𝑥 2 ) ∧ S(f a 𝑥 2 ) ⇒ Q (g (h 𝑦1 ) 𝑥 2 )
As before, the body of the clause in the conclusion can be viewed as closer to our automaton
solved form, but the head of the clause is further away. In fact, the clause has departed the MSL
fragment completely since it no longer has a shallow head! This is a significant problem because,
by inspection, further resolution inferences with this non-MSL clause as the main premise can only
produce clauses with a head of the same or even greater depth.
However, resolving on clauses where the selected negative literal is headed by a variable appears
inescapable if we insist one of the premises of each resolution inference to be automaton:
true ⇒ P(h 𝑦1 𝑦2 ) P(𝑥 1 (f a 𝑥 2 )) ⇒ Q (g 𝑥 1 𝑥 2 ) Q (g (h 𝑧) a) ⇒ false
In this example, we can obtain a contradiction by resolution, but the only automaton clause is the
first one, so there is no choice but to resolve the first and second, which leads to a deep head as
above.
Our solution to this problem is to radically rethink the form of automaton clauses in the higher-
order setting. We observe that a clause with a deep head R(f a 𝑥 2 ) ∧ S(f a 𝑥 2 ) ⇒ Q (g (h 𝑦1 ) 𝑥 2 )
can be thought of as a clause with a shallow head R(f a 𝑥 2 ) ∧ S(f a 𝑥 2 ) ∧ 𝑥 1 = ℎ 𝑦1 ⇒ Q (g 𝑥 1 𝑥 2 )
that contains an additional constraint 𝑥 1 = ℎ 𝑦1 in the body.
Of course, allowing arbitrary equational constraints (and especially at higher type) in the body
will lead us immediately outside of a decidable fragment, so we cannot state such constraints
directly. Rather, we ask only that the higher-order variable 𝑥 1 “behave like” ℎ 𝑦1 . Since 𝑥 1 and
ℎ 𝑦1 are both functions, the most obvious route to making this precise is to ask that they behave
3 Negative literals with depth 0 are essentially already solved.
(Fact1 ) 𝑐:𝜄 ∈ Σ (Fact2 )

⊢𝑃𝑐 :𝑜 𝑥:𝜄 ⊢ 𝑃 𝑥 : 𝑜
𝑦:𝛾 ⊢ 𝑈 : 𝑜 𝑦:𝛾 ⊢ 𝑈 : 𝑜
(ACl1 ) 𝑓 :𝛾 → 𝜄 ∈ Σ (ACl2 )
⊢ ∀𝑦:𝛾 . 𝑈 ⇒ 𝑃 (𝑓 𝑦) : 𝑜 𝑥:𝛾 → 𝜄 ⊢ ∀𝑦:𝛾 . 𝑈 ⇒ 𝑃 (𝑥 𝑦) : 𝑜
Δ1 ⊢ 𝑈 : 𝑜 Δ2 ⊢ 𝑉 : 𝑜
(True) (And) Δ1 = ∅ iff Δ2 = ∅
Δ ⊢ true : 𝑜 Δ1 ∪ Δ2 ⊢ 𝑈 ∧ 𝑉 : 𝑜
Fig. 7. Typing for automaton clauses and formulas
similarly on similar inputs. Moreover, there is a clear way to define similar, because we are only
able to observe the behaviour of terms through the lens of our stock of predicate symbols4 .
Hence, to ask that 𝑥 1 behaves as ℎ 𝑦1 is to ask that 𝑥 1 satisfies (∀𝑦2 . 𝑅(𝑦2 ) ∧ 𝑆 (𝑦2 ) ⇒ 𝑃 (𝑥 1 𝑦2 )).
Clearly, ℎ 𝑦1 is an instance of 𝑥 1 that satisfies this constraint and, we claim, MSL(𝜔) cannot
distinguish between ℎ 𝑦1 and any other 𝑥 1 that also satisfies it.
Incorporating this leads to a kind of abductive inference, in which we infer an additional premise:
P(𝑥 1 (f a 𝑥 2 )) ⇒ Q (g 𝑥 1 𝑥 2 ) R(𝑦1 ) ∧ S(𝑦2 ) ⇒ P(h 𝑦1 𝑦2 )
R(f a 𝑥 2 ) ∧ S(f a 𝑥 2 ) ∧ (∀𝑦2 . R(𝑦2 ) ∧ S(𝑦2 ) ⇒ P(𝑥 1 𝑦2 )) ⇒ Q (g 𝑥 1 𝑥 2 )
Of course, we have still ended up outside the MSL fragment, but the additional power required
to state this form of constraint on 𝑥 1 seems much less dangerous. This nested implication is none
other than an MSL clause itself – the head is shallow and linear – and, moreover, its body is already
in the correct form to be automaton. In fact we show that this form of nested clause is exactly the
generalisation of automaton clause that we need in the higher-order setting.
4.2 Higher-Order Automaton Formulas

Higher-order automaton formulas allow for the nesting of clauses inside the body of other clauses.
This makes them more properly a fragment of higher-order hereditary Harrop formulas (HOHH).
In fact it is easy to see that they are HOHH formulas of a special kind, since they live in the
intersection of HOHH goal and definite formulas [for HOHH see e.g. Miller et al. 1991].
Definition 4.1 (Automaton Formulas). Define the automaton formulas, typically 𝑈 and 𝑉 , by the
following grammar:
(Automaton Fm) 𝑈, 𝑉 F true | 𝑈 ∧ 𝑉 | 𝑃 𝑥 | 𝑃 𝑐 | ∀𝑦:𝛾 . 𝑈 ⇒ 𝑃 (𝑓 𝑦) | ∀𝑦:𝛾 . 𝑈 ⇒ 𝑃 (𝑥 𝑦)
Note: the form 𝑃 𝑥 concerns such a particular free 𝑥 (i.e. it is not ∀𝑥 . 𝑃 𝑥). We identify formulas and
clauses up to renaming of bound variables and we identify up to the commutativity, associativity,
and idempotence of conjunction, with true as a unit, so that a formula 𝑈 will be thought of equally
well as a set of conjuncts. We only consider formulas Δ ⊢ 𝑈 : 𝑜 that are well typed according to the
judgement of Figure 7.
Each clause in 𝑈 is essentially monadic, and by this we mean that it concerns either a single free
variable 𝑥 or a single constant 𝑐 or 𝑓 from the signature. This can be seen in the two pairs of rules
(Fact1 ), (ACl1 ) and (Fact2 ), (ACl2 ), which have an empty and singleton typing context respectively.
In automaton formulas, clauses can be nested inside the body of another, and one function of
the type system is to ensure some stratification to the nesting. In particular, in a closed automaton
4 Forexample, if we only had a single predicate 𝑃 then all terms 𝑠 for which 𝑃 (𝑠) is true are alike, we have no mechanism to
write a constraint that distinguishes them.
formula (i.e. without free variables), top-level clauses can only concern constants from the signature
and strictly nested clauses can only concern variables introduced by the clause that immediately
contains them. To this end, note that the type context on the single premise of (ACl1 ) and (ACl2 )
contains exactly the variables 𝑦:𝛾 introduced by the universal quantifier prefixing the immediately
enclosing clause. The side condition of (And) guarantees that each conjunction of automaton clauses
contains subjects from the same nesting level, rejecting ill-formed clauses like (5)-(8) below.
Since there is no weakening in general in this type system, the context 𝑦:𝛾 introduced on the
premise of (ACl1 ) and (ACl2 ) implies that the body 𝑈 must contain a constraint concerning each
of the variables in 𝑦:𝛾. These variables can be distributed to the appropriate conjuncts of 𝑈 that
contain the corresponding constraint by the (And) rule. However, note that, despite the lack of
weakening, it is possible to leave a subset of the variables, say 𝑦 ′:𝛾 ′ unconstrained, but formally
we must do that by introducing a true conjunct and discharge it by the judgement 𝑦:𝛾 ′ ⊢ true : 𝑜.
Since, in practice, we will typically omit true conjuncts we will consider, for example, the clause
∀𝑥𝑦. 𝑃 𝑥 ⇒ 𝑅 (𝑎 𝑥 𝑦) to be well typed with 𝑃 : 𝜄 → 𝑜 and 𝑎 : 𝜄 → 𝜄 → 𝜄 by regarding the body 𝑃 𝑥
as sugar for 𝑃 𝑥 ∧ true.
For example, the following are closed automaton clauses over predicate symbols 𝑃, 𝑄, 𝑅 : 𝜄 → 𝑜
and tree constructor symbols 𝑎 : 𝜄, 𝑏 : 𝜄 → 𝜄 → 𝜄, 𝑐 : (𝜄 → 𝜄) → 𝜄 → 𝜄, and 𝑑 : ((𝜄 → 𝜄) → 𝜄) → 𝜄.
𝑃𝑎 (1)
∀𝑥𝑦. 𝑃 𝑥 ∧ 𝑄 𝑥 ⇒ 𝑅 (𝑏 𝑥 𝑦) (2)
∀𝑥𝑦. 𝑄 𝑦 ∧ (∀𝑧. 𝑄 𝑧 ⇒ 𝑅 (𝑥 𝑧)) ⇒ 𝑃 (𝑐 𝑥 𝑦) (3)
∀𝑥 . (∀𝑦. (∀𝑧. 𝑃 𝑧 ∧ 𝑄 𝑧 ⇒ 𝑅 (𝑦 𝑧)) ⇒ 𝑅 (𝑥 𝑦)) ⇒ 𝑃 (𝑑 𝑥) (4)
Note: strictly speaking clause (2) must be constructed as e.g. ∀𝑥𝑦. 𝑃 𝑥 ∧𝑄 𝑥 ∧ true ⇒ 𝑅 (𝑏 𝑥 𝑦) (with
true representing the constraint on 𝑏’s argument 𝑦). However, the following are not well formed as
closed automaton clauses:
𝑃𝑥 (5)
∀𝑥𝑦. 𝑃 𝑥 ∧ 𝑄 𝑎 ⇒ 𝑅 (𝑏 𝑥 𝑦) (6)
∀𝑥𝑦. 𝑄 𝑦 ∧ (∀𝑧. 𝑄 𝑧 ∧ 𝑅 𝑦 ⇒ 𝑅 (𝑥 𝑧)) ⇒ 𝑃 (𝑐 𝑥 𝑦) (7)
′ ′ ′
∀𝑥 . (∀𝑦. (∀𝑧. 𝑃 𝑧 ∧ (∀𝑧 . 𝑄 𝑧 ⇒ 𝑅 (𝑦 𝑧 )) ⇒ 𝑅 (𝑦 𝑧)) ⇒ 𝑅 (𝑥 𝑦)) ⇒ 𝑃 (𝑑 𝑥) (8)
In (5) we have a free variable 𝑥, yet the clause is supposed to be closed. In (6) we have an atom
𝑄 𝑎 concerning a constant that appears in a strictly nested position and in (7) we have an atom 𝑅 𝑦
that concerns a variable from an outer scope – predicates that appear in nested clauses can only
concern variables, and only variables that are introduced by the clause that immediately contains
them. This is also the problem in clause (8), where the nested clause (∀𝑧 ′ . 𝑄 𝑧 ′ ⇒ 𝑅 (𝑦 𝑧 ′)) concerns
𝑦, but 𝑦 is not a variable introduced by the immediately enclosing clause (∀𝑧. 𝑃 𝑧 . . . ⇒ 𝑅 (𝑦 𝑧)),
which introduces only 𝑧.
Notation. If 𝑈 is automaton wrt 𝑦 𝑧 (i.e. 𝑦 and 𝑧 are the free variables in 𝑈 ), we write 𝑈 |𝑦 and 𝑈 |𝑧
for the partition 𝑈 = 𝑈 |𝑦 ∧ 𝑈 |𝑧 according to whether the automaton clauses in 𝑈 contain a (free)
variable from either 𝑦 or 𝑧.
Say that an automaton clause 𝑇 of shape ∀𝑦. 𝑈 ⇒ 𝑃 (𝜉 𝑦) (for 𝜉 either a variable or a constant) is
order 𝑛 just if the type of 𝜉 is order 𝑛. Note that the type system ensures that clauses that are nested
in the body of an order-𝑛 clause are of strictly smaller order. In the following, exp𝑛 (𝑚) denotes a
𝑚
tower of exponentials of height 𝑛 + 1, with exp1 (𝑚) = 2𝑚 , exp2 (𝑚) = 22 , etc.
Theorem 4.2. Let 𝑘 denote the largest arity of any function symbol in Σ and |Π| denote the number
of predicate symbols in Π. There are 𝑂 (exp𝑛 (𝑘 |Π|)) clauses 𝑇 such that 𝑥 : 𝛾 ⊢ 𝑇 : 𝑜, for ord(𝛾) = 𝑛.
Proof. Fix an order-1 variable 𝑥 and consider an order-1 clause ∀𝑦. 𝑈 ⇒ 𝑃 (𝑥 𝑦). Since every
variable of 𝑦 is of type 𝜄, the body 𝑈 cannot contain any nested clauses, so every conjunct is of the
form 𝑃 ′𝑦. Hence, order-1 clauses coincide with the automaton clauses of first-order MSL, and it is
𝑘
easy to see that there are at most |Π| · 2 |Π | = 𝑂 (2𝑘 |Π | ) different such, where 𝑘 is the maximum arity
of any function symbol. Now consider an order-(𝑛 + 1) clause ∀𝑦. 𝑈 ⇒ 𝑃 (𝑥 𝑦). In the worst case,
each variable 𝑦 of 𝑦 is order 𝑛, and we may assume there are 𝑂 (exp𝑛 (𝑘 |Π|)) clauses that concern 𝑦.
Hence, choosing this automaton clause amounts to choosing the predicate 𝑃 in the head and then,
for each variable 𝑦 ∈ 𝑦, choosing some subset of the 𝑂 (exp𝑛 (𝑘 |Π|)) different clauses that can be
nested inside 𝑈 . Hence, we have 𝑂 (exp𝑛+1 (𝑘 |Π|)) many clauses at most. □
Automaton clauses 𝑇 that concern a function symbol 𝑓 : 𝛾, i.e. for which ⊢ 𝑇 : 𝑜 holds, are just
automaton clauses of the above form in which we have replaced the variable 𝑥 by 𝑓 . Hence:
Corollary 4.3. There are finitely many automaton clauses of a given order.
4.3 Decision Procedure

Our decision procedure takes a set of MSL(𝜔) definite clauses 𝐷 as input and iteratively rewrites
them into automaton form 𝑉 . By construction, the new set of automaton clauses 𝑉 is sufficiently
strong, though generally weaker than 𝐷, to entail any goal 𝐺 that follows from 𝐷.
Although we have so far been discussing resolution on clauses, the rewriting will be defined
only for goals. This is because rewriting will introduce nested clauses, and it seems easier to reason
with nested clauses compositionally a la Miller et al. [1991].
Definition 4.4 (Rewriting). Given an automaton formula 𝑉 , variables 𝑦, and two goal clauses 𝐺
and 𝐻 , we introduce the rewrite relation 𝑉 , 𝑦 ⊢ 𝐺 ⊲ 𝐻 defined by the rules in Figure 8. Note that, in
(Assm), we implicitly assume that the length of 𝑧 is the same as the length of 𝑠.
The rules are mostly straightforward, and consist of simulating certain standard logical inference
steps directly on the syntax of the formula. The heavy lifting is done by (Step) and (Assm) which
simulate resolution steps on a goal. The first, (Step), applies when the head symbol of the goal is a
function symbol and the second, (Assm), applies when it is a variable. Thus the latter provides the
abductive method of adding an assumption described above.
The automaton formula 𝑉 is the set of automaton clauses that we are allowed to use when
performing resolution steps and the variables 𝑦 that appear before the turnstile are the set of
variables that we are willing to make additional assumptions about, via (Assm). The idea is that,
although we are only rewriting goal formulas 𝑉 , 𝑦 ⊢ 𝐺 ⊲∗ 𝐻 , we can think of the goal formula 𝐺 as
the body of an MSL(𝜔) clause ∀𝑦. 𝐺 ⇒ 𝐴. Then the outcome of rewriting, namely 𝐻 , will give us a
new clause ∀𝑦. 𝐻 ⇒ 𝐴, but we need to be sure we have only made additional assumptions about
the top-level universally quantified variables 𝑦. This is justified by the following theorem and the
remarks that follow.
Theorem 4.5 (Soundness). If 𝑉 , 𝑦 ⊢ 𝐺 ⊲∗ 𝐻 then 𝑉 |= ∀𝑦. 𝐻 ⇒ 𝐺.
It follows that, if 𝑉 , 𝑦 ⊢ 𝐺 ⊲∗ 𝐻 , then 𝑉 ∧ (∀𝑦. 𝐺 ⇒ 𝐴) ⊨ (∀𝑦. 𝐻 ⇒ 𝐴). In practice, we are
only interested in rewriting sequences that start with the body of a non-solved clause and end
in an automaton formula, giving us new automaton clauses. Termination of branches that have
successfully reached automaton form is ensured by e.g. the side conditions of (Imp) and (Scope).
The new automaton clauses arising this way unlock additional avenues to rewrite the remaining
𝑃𝑥 ∈𝑉 (Refl) (∀𝑥 . 𝑈 ⇒ 𝑃 (𝑓 𝑥)) ∈ 𝑉 (Step)

𝑉 , 𝑦 ⊢ 𝑃 𝑥 ⊲ true 𝑉 , 𝑦 ⊢ 𝑃 (𝑓 𝑠) ⊲ 𝑈 [𝑠/𝑥]
(∀𝑥𝑧. 𝑈 ⇒ 𝑃 (𝑓 𝑥𝑧)) ∈ 𝑉 (Assm)

𝑉 , 𝑦 ⊢ 𝑃 (𝑦 𝑠) ⊲ 𝑈 |𝑧 [𝑠/𝑧] ∧ (∀𝑧. 𝑈 |𝑧 ⇒ 𝑃 (𝑦 𝑧))
𝑉, 𝑦 ⊢ 𝐺 ⊲ 𝐺′ 𝐺 ≠ 𝑃 (𝑦 𝑧) 𝑈 ∧ 𝑉, 𝑦 ⊢ 𝐺 ⊲ 𝐺′
(AndL) (Imp)
𝑉, 𝑦 ⊢ 𝐺 ∧ 𝐻 ⊲ 𝐺′ ∧ 𝐻 for any 𝑦 ∈ 𝑦 𝑉 , 𝑦 ⊢ (∀𝑧. 𝑈 ⇒ 𝐺) ⊲ (∀𝑧. 𝑈 ⇒ 𝐺 ′)
𝑉, 𝑦 ⊢ 𝐻 ⊲ 𝐻′
(AndR) 𝑧 ∩ FV(𝐺) = ∅ (Scope)
𝑉, 𝑦 ⊢ 𝐺 ∧ 𝐻 ⊲ 𝐺 ∧ 𝐻′ 𝑉 , 𝑦 ⊢ ∀𝑧. 𝑈 ⇒ 𝐺 ⊲ 𝐺
(ImpAnd)
𝑉 , 𝑦 ⊢ (∀𝑧. 𝐺 1 ⇒ 𝐺 2 ∧ 𝐺 3 ) ⊲ (∀𝑧. 𝐺 1 ⇒ 𝐺 2 ) ∧ (∀𝑧. 𝐺 1 ⇒ 𝐺 3 )
Fig. 8. Rewrite system
MSL(𝜔) clauses (via (Step) and (Assm)) and this, in turn, generates more automaton clauses and so
on. It follows from Corollary 4.3 that, for a given set of definite clauses 𝐷, the limit, V (𝐷), is a
finite object.
Definition 4.6 (Canonical solved form). Define the canonical solved form, written V (𝐷), of a set
of definite clauses 𝐷 inductively by the following rule. The base case – when 𝑉 is empty – occurs
for definite clauses that are already automaton, like ∀𝑦1𝑦2 . 𝑃 𝑦1 ∧ 𝑅 𝑦1 ⇒ 𝑆 (𝑓 𝑦1 𝑦2 ).
(∀𝑦. 𝐺 ⇒ 𝐴) ∈ 𝐷 𝑉 ⊆ V (𝐷)
𝑉 , 𝑦 ⊢ 𝐺 ⊲∗ 𝑈 (∀𝑦. 𝑈 ⇒ 𝐴) ∈ V (𝐷)
Since every clause that we add to V (𝐷) is weaker than a clause in 𝐷, we have V (𝐷) |= 𝐺 implies
𝐷 |= 𝐺. It remains to show the converse, from which we deduce that satisfiability can be decided
by computing V (𝐷) and then checking whether or not the goal follows.
Theorem 4.7 (Completeness). If 𝐷 ⊢ 𝐺 then V (𝐷) |= 𝐺.
It follows from the fact that there are only finitely many automaton clauses that the canonical
solved form is finite. Furthermore, as the rewrite system is well founded and terminates, we can
effectively decide whether a given automaton clause is in the canonical solved form. Hence, we can
compute V (𝐷) by enumerating the possible automaton clauses and checking if they are the solved
form of any clause in 𝐷.
Theorem 4.8 (Decidability). Let 𝑉 be an automaton formula, 𝑦 variables, 𝐺 an goal formula and
𝑈 an automaton formula. Then 𝑉 , 𝑦 ⊢ 𝐺 ⊲∗ 𝑈 is decidable. Hence, V (𝐷) is computable.
Remark. In principle, all fragments identified in Section 2.2 can be decided by our decision
procedure. Strictly speaking, the procedure takes as input an existential-free formula of MSL(𝜔)
(and thus of any of the syntactic subfragments MSL(𝑛)). However, our translations from Section 3
allow for transforming any formula of HOMSL(𝜔) or a HOMSL(𝑛) subfragment thereof into an
equi-satisfiable existential-free formula of MSL(𝜔). Existentials have been eliminated for simplicity;
we could have introduced new rules to the calculus to handle them natively.
4.4 Rewriting Example

By way of an example, we show how to use rewriting to obtain automaton clauses (i.e. a subset
of V (𝐷)) from the given formulas in Figure 3 that allow for a replay of the proof in Figure 4.
One can view this as a concrete example of the completeness proof in action. The strategy of the
completeness argument is to start from the leaves of the proof tree, where resolution steps already
involve automaton clauses5 , and work back towards the root. We start at the leaf labelled with (18).
Since clauses (18) and (7) are already automaton, we can use (7) to rewrite the body of clause (10)
using (Assm):
V(𝑥 ℎ (putCont 𝑘)) ⊲ Closed(ℎ) ∧ (∀ℎ 𝑘. Closed(ℎ) ⇒ V (𝑥 ℎ 𝑘))
From this, we obtain (10’): Closed(ℎ) ∧ (∀ℎ 𝑘. Closed(ℎ) ⇒ V (𝑥 ℎ 𝑘)) ⇒ V(putStrLn 𝑥 ℎ 𝑘) is an

automaton clause in V (𝐷). Continuing down the tree, we can use (10’) to rewrite the body of (16)
using (Step):
V(putStrLn 𝑥 ℎ 3 id) ⊲ Closed(ℎ 3 ) ∧ (∀ℎ 𝑘. Closed(ℎ) ⇒ V (𝑥 ℎ 𝑘))
thus obtaining (16’): Closed(ℎ 3 )∧(∀ℎ 𝑘. Closed(ℎ) ⇒ V (𝑥 ℎ 𝑘)) ⇒ V(act2 𝑥 ℎ), another automaton
clause. Following the proof branch down, we can use (16’) to rewrite the body of (14) using (Assm):
Closed(ℎ 2 ) ∧ (∀ℎ 𝑘. Closed(ℎ) ⇒ V (𝑦 ℎ 𝑘))

V(𝑘 𝑦 ℎ 2 ) ⊲
∧(∀𝑥 ℎ. Closed(ℎ) ∧ (∀ℎ 𝑘. Closed(ℎ) ⇒ V (𝑥 ℎ 𝑘)) ⇒ V(𝑘 𝑥 ℎ))
and, naming that formula 𝑈 for brevity, we obtain (14’): ∀𝑦 𝑘 ℎ 2 . 𝑈 ⇒ V(withFile3 𝑦 𝑘 ℎ 2 ). At any
point we can stop and the automaton clauses we have obtained are sufficient to entail the goal at
the same place in the tree. For example, it is easy to check that any model of the automaton clauses
we have collected so far satisfies V(withFile3 read act2 c).
5 AUTOMATON CLAUSES: CONNECTING LOGIC, TYPES, AND AUTOMATA

Recall that our ‘automaton clauses’ are named after their first-order counterparts in Goubault-
Larrecq [2002]. We argue that this name is equally justified for our higher-order automaton clauses.
While it is easy to see that a first-order automaton clause ∀𝑥 𝑦. 𝑃 𝑥 ∧ 𝑄 𝑦 ∧ 𝑅 𝑦 ⇒ 𝑆 (𝑓 𝑥 𝑦) fits
the shape of a transition in a finite tree automaton (if 𝑡 1 is accepted from state 𝑃 and 𝑡 2 from states
𝑄 and 𝑅, then 𝑓 𝑡 1 𝑡 2 is accepted from state 𝑆), this relation is more complicated for higher-order
automaton clauses with variable-headed atoms and nested clauses.
Nonetheless, our automaton clauses share a vital trait with automaton transitions: the monadic,
shallow, linear heads ‘peel’ a single constructor off a tree and separate its children without interde-
pendencies. Furthermore, the fact that the number of automaton clauses is 𝑛-exponential in the
order 𝑛 of the program (Theorem 4.2) suggests automaton clauses could be a defunctionalisation of
MSL(𝜔) and, thus, ‘first order’ in a sense – maybe even regular, given they are essentially monadic.
This intuition turns out to be true: automaton clauses correspond to intersection types, which
are known to give rise to alternating tree automata, see Rehof and Urzyczyn [2011] and Broadbent
and Kobayashi [2013], that are equivalent to ordinary non-deterministic finite tree automata.
This correspondence between automaton clauses and intersection types allows us to reduce
MSL(𝜔) provability to intersection untypeability and vice versa, giving us a new algorithm for
solving higher-order recursion scheme (HORS) model checking along the way.
5A resolution step whose conclusion is a leaf must use a clause of shape true ⇒ 𝐴 as premise, which is already automaton.
5.1 Correspondence with Intersection Types

In the remainder of this section, we reserve the word term for terms of constructor types and 𝜏 for
strict types. We follow the practice from HORS model checking in stratifying the definitions of
intersection types for convenience.
Fix (𝑞 ∈) 𝑄 as a set of atomic base types. We define the intersection types and strict types over 𝑄:
(Strict Types) 𝜏 F 𝑞 | 𝜎t → 𝜏 (Intersection Types) 𝜎t F 𝑛𝑖=1 𝜏𝑖
Ó
Arrows associate to the right; intersections bind tightest. An intersection type environment, written
Γ, is a finite, partial function from variables to intersection types. We denote an arbitrary strict
or intersection type by 𝜃 and refer to it WLOG as an intersection type (since strict types are
intersection types with 𝑛 = 1). We assume types are well typed, where base types 𝑞 have type 𝜄.
An intersection (refinement) type system is a triple (Σ, 𝑄, type) in which Σ is a signature of
constants, 𝑄 a set of base types equipped with a preorder Θ, and type assigns an intersection type
of type 𝜎 to each 𝑎 : 𝜎 ∈ Σ. The subtype relation over 𝑄 is the least relation on types, written ≤,
that validates standard subtyping rules (see the long version of this work for details).
Terms can be typed in the following way:
type(𝑐) = 𝑛𝑖=1 𝜏𝑖
Ó
(T-Con) (T-Var)
Γ ⊢ 𝑐 :: 𝜏𝑖 Γ, 𝑥 :: 𝑛𝑖=1 𝜏𝑖 ⊢ 𝑥 :: 𝜏𝑖
Ó
Γ ⊢ 𝑠 :: 𝜎t → 𝜏 Γ ⊢ 𝑡 :: 𝜏𝑖 (∀𝑖 ∈ [1..𝑛]) Ó𝑛
(T-App) 𝑖=1 𝜏𝑖 ≤ 𝜎t
Γ ⊢ 𝑠 𝑡 :: 𝜏
We may write Γ ⊢ 𝑡 :: 𝜎t as a shorthand for 𝜏 ∈𝜎t (Γ ⊢ 𝑡 :: 𝜏).
Ó
We consider intersection type systems (Σ, 𝑄, type) with a trivial preorder, i.e. Θ = {(𝑞, 𝑞) | 𝑞 ∈ 𝑄 }.
This is not a restriction, because non-trivial preorders can be simulated with fresh base types. For
example, nat ≤ int can be enforced with a fresh base type pos by replacing nat by int ∧ pos.
5.1.1 Type-Clause Correspondence. Recall that automaton clauses are essentially monadic; each
automaton clause contains precisely one symbol of type 𝛾 that is not locally bound, either a free
variable or a constructor from signature Σ.
Given an automaton clause 𝑇 with top-level variable 𝑥, an instantiation 𝑇 [𝑡/𝑥] rewrites to true
just if 𝑡 satisfies the constraints imposed by 𝑇 . Clearly, 𝑇 [𝑡/𝑥] rewrites to true iff 𝑇 [𝑦/𝑥] [𝑡/𝑦] does;
after all, 𝑥 and 𝑦 are the only free variables in 𝑇 and 𝑇 [𝑦/𝑥], resp. This means automaton clauses 𝑇
and 𝑇 [𝑦/𝑥] are indistinguishable wrt the constraints they impose on their respective variables.
In this section, we discuss the constraints imposed by automaton clauses and formulas. It will be
helpful to think of an automaton clause as forgetful with regards to its top-level symbol. As we
shall see below, forgetful automaton clauses (hereafter just ‘automaton clauses’) correspond to
strict intersection types over base types Π; an instantiated automaton clause 𝑇 [𝑡/𝑥] rewrites to
true precisely when closed term 𝑡 has the strict type corresponding to 𝑇 and vice versa.
Automaton formulas and intersection types are simply two (equivalent) ways of imposing
constraints on 𝑡.
Definition 5.1 (Correspondence between automaton clauses and intersection types). The following
typing rules define a one-to-one correspondence between intersection types and MSL(𝜔) automaton
formulas. We assign an intersection type 𝜃 of type 𝜎1 → · · · → 𝜎𝑚 → 𝜄 to automaton formula
𝑈 = 𝑈 |𝑥 1 ∧ · · · ∧ 𝑈 |𝑥𝑚 with 𝑥 1 : 𝜎1, . . . , 𝑥𝑚 : 𝜎𝑚 , written 𝑈 :: 𝜃 :
𝑈 |𝑥 1 :: 𝜃 1 . . . 𝑈 |𝑥𝑚 :: 𝜃𝑚 𝑈 1 |𝑥 :: 𝜃 1 𝑈 2 |𝑥 :: 𝜃 2
true :: ⊤ 𝑃 𝜉 :: 𝑞𝑃 (∀𝑥 . 𝑈 ⇒ 𝑃 (𝜉 𝑥)) :: 𝜃 1 → · · · → 𝜃𝑚 → 𝑞𝑃 𝑈 1 |𝑥 ∧ 𝑈 2 |𝑥 :: 𝜃 1 ∧ 𝜃 2
where 𝑞𝑃 ∈ 𝑄 is a basetype and 𝜉 a variable or constructor from Σ.
We write fromCl(𝑈 ) = 𝜃 for 𝑈 :: 𝜃 , and toCl(𝜃 )(𝑓 ) = 𝑈 for 𝑈 :: 𝜃 with 𝑓 as top-level constructors.
We write 𝑈 ≤a 𝑈 ′ for 𝑈 , 𝑈 ′ over 𝑥 1 . . . 𝑥𝑚 just if ∀𝑖 ∈ [1..𝑚]. fromCl(𝑈 |𝑥𝑖 ) ≤ fromCl(𝑈 |𝑥′ 𝑖 ).
Example 5.2. Let 𝑈 = ∀𝑣 𝑥 𝑦. 𝑄 𝑦 ∧ (∀𝑧. 𝑄 𝑧 ∧ 𝑃 𝑧 ⇒ 𝑅 (𝑥 𝑧)) ⇒ 𝑃 (𝑐 𝑣 𝑥 𝑦). The following hold:
fromCl(𝑈 ) = ⊤ → (𝑞𝑄 ∧ 𝑞𝑃 → 𝑞𝑅 ) → 𝑞𝑄 → 𝑞𝑃
𝑈 = toCl(⊤ → (𝑞𝑄 ∧ 𝑞𝑃 → 𝑞𝑅 ) → 𝑞𝑄 → 𝑞𝑃 )(𝑐)
This is witnessed by:
𝑄 𝑧 :: 𝑞𝑄 𝑃 𝑧 :: 𝑞𝑃
true :: ⊤ ∀𝑧. 𝑄 𝑧 ∧ 𝑃 𝑧 ⇒ 𝑅 (𝑥 𝑧) :: 𝑞𝑄 ∧ 𝑞𝑃 → 𝑞𝑅 𝑄 𝑦 :: 𝑞𝑄
∀𝑣 𝑥 𝑦. 𝑄 𝑦 ∧ (∀𝑧. 𝑄 𝑧 ∧ 𝑃 𝑧 ⇒ 𝑅 (𝑥 𝑧)) ⇒ 𝑃 (𝑐 𝑣 𝑥 𝑦) :: ⊤ → (𝑞𝑄 ∧ 𝑞𝑃 → 𝑞𝑅 ) → 𝑞𝑄 → 𝑞𝑃
Lemma 5.3 (Order isomorphism). Let 𝜃, 𝜃 1, 𝜃 2 be intersection types of type 𝜎1 → · · · → 𝜎𝑚 → 𝜄

and 𝑈 , 𝑈 1, 𝑈 2 automaton clauses over 𝑥 = 𝑥 1 . . . 𝑥𝑚 with 𝑥𝑖 : 𝜎𝑖 , for all 𝑖 ∈ [1..𝑚]. The following hold:
(i) toCl(fromCl(𝑈 ))(𝑥) = 𝑈
(ii) fromCl(toCl(𝜃 )(𝑥)) = 𝜃
(iii) 𝜃 1 ≤ 𝜃 2 if, and only if, toCl(𝜃 1 )(𝑥) ≤a toCl(𝜃 2 )(𝑥)
(iv) fromCl(𝑈 1 ) ≤ fromCl(𝑈 2 ) if, and only if, 𝑈 1 ≤a 𝑈 2
This isomorphism between automaton formulas and intersection types extends to intersection
type systems (Σ, 𝑄, type) and MSL(𝜔) automaton formulas 𝑉 over signatures (Π, Σ ′): MSL(𝜔)
predicates Π correspond to basetypes 𝑄; automaton environment 𝑉 corresponds to intersection
type environment Γ ⊎ type, both with domain dom(Γ) ∪ Σ = Σ ′.
Definition 5.4 (Correspondence between automaton formulas and intersection type systems). We
map intersection type system (Σ, 𝑄, type) with type environment Γ to MSL(𝜔) automaton formula
𝑉Σ,Γ over signatures (Π𝑄 , Σ ∪ dom(Γ)) using:
Π𝑄 := {𝑃 | 𝑞𝑃 ∈ 𝑄 } 𝑉Σ,Γ := {toCl(type(𝑓 ))(𝑓 ) | 𝑓 ∈ Σ} ∪ {toCl(𝜃 )(𝑎) | 𝑎 :: 𝜃 ∈ Γ}
In the converse direction, we map an MSL(𝜔) automaton formula 𝑉 over (Π, Σ) to an intersection
type system (∅, 𝑄 Π , ∅) with type environment Γ𝑉 :

𝑄 Π := {𝑞𝑃 | 𝑃 ∈ Π} Γ𝑉 := 𝑎 :: 𝜃 𝑎 ∈ dom(𝑉 ) ∧ fromCl(𝑉 |𝑎 ) = 𝜃
The above is not strictly a one-to-one correspondence, because the separate environments type
and Γ for intersection-type ‘constants’ and ‘variables’, resp., are mapped to a single automaton
formula 𝑉 . This distinction cannot be recovered in the other direction. Note, however, that (T-Con)
and (T-Var) both choose a strict type from Γ ⊎ type for a symbol. For the typeability of a term it
does not matter whether a symbol lives in the domain of Γ or type.
Since the same typing judgements hold for (Σ, 𝑄, type) with type environment Γ as for (∅, 𝑄, ∅)
with type environment Γ ⊎ type, we identify Γ𝑉Σ,Γ and Γ with type left implicit. Clearly, 𝑉Γ𝑉 = 𝑉 ,
which gives us a one-to-one correspondence after all. Furthermore, because Γ𝑉Σ,Γ and Γ type the
same terms, we may assume WLOG that our intersection type systems do not contain constants,
thus, 𝑉Σ,Γ = 𝑉Γ , giving rise to the following lemma.
Lemma 5.5. 𝑉Γ𝑉 = 𝑉 and Γ𝑉Γ = Γ.
5.1.2 Typing-Rewriting Correspondence. Unless otherwise specified, we consider only goal formulas
𝐺 that result from rewriting some existential-free MSL(𝜔) goal formula 𝐺 ′, i.e. 𝑉 , 𝑦 ⊢ 𝐺 ′ ⊲∗ 𝐺. Such
a 𝐺 is itself existential-free, and all its implications have automaton bodies, as rewriting does not
introduce existentials and only introduces implications with automaton bodies.
Given an isomorphic type environment and automaton formula as per Definition 5.4, we can
now formalise the equivalence between typing judgements and rewrites.
Proposition 5.6 (Typing-rewriting correspondence).
(i) For all 𝑈 over 𝑦, there exists 𝑈 ′ such that 𝑈 ≤a 𝑈 ′ and 𝑉 , 𝑦 ⊢ toCl(𝜎t )(𝑡) ⊲∗ 𝑈 ′ if, and only if,
Γ𝑉 , 𝑦 :: fromCl(𝑈 ) ⊢ 𝑡 :: 𝜎t .
(ii) 𝑉 ⊢ toCl(𝜎t )(𝑡) ⊲∗ true if, and only if, Γ𝑉 ⊢ 𝑡 :: 𝜎t
Thanks to Γ𝑉Γ = Γ, the above not only provides an equivalence between 𝑉 and Γ𝑉 but also
between 𝑉Γ and Γ.
5.2 Reducing HORS Intersection Typing to MSL(𝜔)

One of the most well-studied problems in higher-order model checking is the safety problem for
higher-order recursion schemes (HORS): does the tree JGK generated by HORS G satisfy safety prop-
erty 𝜑? The property is typically expressed as an alternating trivial automaton – or its negation as
an alternating cotrivial automaton. This problem reduces to intersection (un)typeability [Kobayashi
2009], which we shall use.
A higher-order recursion scheme (HORS) is a set R of well-typed ground definitions of type 𝜄
(i.e. the RHSs are applicative terms over the formal parameters, constants Σcon , and variables N ):
{𝑓1 𝑦1 = 𝑡 1, ..., 𝑓𝑛 𝑦𝑛 = 𝑡𝑛 }
where 𝑓1, . . . , 𝑓𝑛 ∈ N and 𝑦1, . . . , 𝑦𝑛 ∈ Vars are vectors of distinct variables. There is a designated
nullary start symbol 𝑆 : 𝜄, so a HORS can be denoted by a quadruple G = ⟨N, Σcon, R, 𝑆⟩.
See e.g. Ong [2006] for a full account of HORS.
For the HORS safety problem, we assume a HORS comes equipped with base types 𝑄 𝜄 and a
negative typing of constants Σcon , denoted by type, with respect 𝑄 𝜄 . This gives rise to an intersection
type system (Σcon, 𝑄 𝜄 , type). Typically, we will ask whether ⊢ 𝑆 :: 𝑞 0 in this system, for some 𝑞 0 ∈ 𝑄 𝜄 .
Negative Types. Negative constant types are easily computable via a DeMorgan dual; if we read a
(positive) type 𝑓 :: 𝑖 ∈ [1..𝑛] (𝜎t𝑖,1 → · · · → 𝜎t𝑖,𝑚 → 𝑞𝑃 ) as 𝑓 𝑡 1 . . . 𝑡𝑚 :: 𝑞𝑃 iff 𝑖 ∈ [1..𝑛] 𝑗 ∈ [1..𝑚] 𝑡 𝑗 ::
Ó Ô Ó
𝜎t𝑖,𝑗 , then the corresponding negative type is the DeMorgan dual of this boolean formula (see
e.g. Muller and Schupp [1987], who use this construction to negate alternating tree automata).
Since we use only negative types but forget about this for the remainder of the section, we shall
simply write 𝑡 :: 𝜏 to mean 𝑡 has negative type 𝜏.
Example 5.7. Consider integer-division operator div with an error type:
(⊤ → zero → err) ∧ (err → ⊤ → err) ∧ (⊤ → err → err)
This means that 𝑛 div 𝑚 :: err iff (𝑛 :: ⊤ ∧ 𝑚 :: zero) ∨ (𝑛 :: err ∧ 𝑚 :: ⊤) ∨ (𝑛 :: ⊤ ∧ 𝑚 :: err). The
corresponding negative type can be computed via DeMorgan as (err → zero ∧ err → err), which
should be read as: “𝑛 div 𝑚 does not have type err if neither 𝑛 or 𝑚 has type err and 𝑚 does not
have type zero.”
Example 5.8. Consider order-2 HORS G2 = ⟨{𝑆, 𝐹, 𝐵}, {c, s, z}, R, 𝑆⟩ that generates a binary
0 1 2
c-labelled spine whose left subtrees are unary s2 z, s2 z, s2 z, etc. in that order, with R given by:
𝑆=𝐹s 𝐹 𝜑 = c (𝜑 z) (𝐹 (𝐵 𝜑 𝜑)) 𝐵 𝜑 𝜓 𝑥 = 𝜑 (𝜓 𝑥)
Let base types 𝑄 = {𝑞𝑆 , 𝑞 0, 𝑞 1, 𝑞 2, 𝑞 3 } count the number of s in a sequence modulo 4. Because
we are considering a negative typing, the constant z has type 𝑞 1 ∧ 𝑞 2 ∧ 𝑞 3 instead of 𝑞 0 and s type
𝑖 ∈ [0..3] (𝑞𝑖 → 𝑞𝑖+1 mod 4 ). Let 𝑞𝑆 model “has no odd subtrees”, so c has negative type:
Ó
type(c) = (𝑞 1 ∧ 𝑞 3 → 𝑞𝑆 → 𝑞𝑆 )
Now we may ask whether ⊢ 𝑆 :: 𝑞𝑆 . Note that type(c) means a c-headed tree has no odd subtrees if
the left (s-headed) subtree isn’t odd and the right (c-headed) subtree does not have odd subtrees.
The HORS Untypeability Problem. We call an intersection type environment Γ G-coconsistent just
if, (1) Γ is empty, or (2) there exist 𝑓 :: 𝜏 ∈ Γ and (𝑓 𝑦 = 𝑡) ∈ G such that Γ\{𝑓 :: 𝜏 } is G-coconsistent
and Γ\{𝑓 :: 𝜏 }, 𝑦 :: 𝜎t ⊢ 𝑡 :: 𝑞𝑃 , where 𝜏 = 𝜎t1 → · · · → 𝜎t𝑚 → 𝑞𝑃 . Intuitively, every intersection
type in a G-coconsistent Γ is (finitely) required by some program definition (𝑓 𝑦 = 𝑡) ∈ G. Thus, a
G-coconsistent type environment corresponds to a finite trace of an intersection typing for G.
We prove that an instance of the HORS untypeability problem (does there exist a G-coconsistent
type environment Γ such that Γ ⊢ 𝑆 :: 𝑞 0 ?) reduces to MSL(𝜔) provability by adapting the rewriting
algorithm to construct an intersection type environment instead of a canonical solved form.
Theorem 5.9. HORS intersection untypeability reduces to MSL(𝜔) provability.
We convert ground definitions from G to definite clauses 𝐷 G by wrapping both sides in a predicate
𝑃 for each base type 𝑞𝑃 ∈ 𝑄 𝜄 . This gives us (𝑓 𝑦 = 𝑡) ∈ G if, and only if, (∀𝑦. 𝑃 𝑡 ⇒ 𝑃 (𝑓 𝑦)) ∈ 𝐷 G
for all 𝑞𝑃 ∈ 𝑄 𝜄 . Furthermore, the types of Σcon are added to 𝐷 G as automaton clauses, giving rise to:
𝐷 G := {∀𝑦. 𝑃 𝑡 ⇒ 𝑃 (𝑓 𝑦) | (𝑓 𝑦 = 𝑡) ∈ G ∧ 𝑡 : 𝜄 ∧ 𝑞𝑃 ∈ 𝑄 𝜄 } ∪ {toCl(𝜏)(𝑐) | 𝑐 :: 𝜏 ∈ Σcon }6
For our example G2 , 𝐷 G2 looks as follows:
𝐷 G2 :={(𝑃 (𝐹 s) ⇒ 𝑃 𝑆), (∀𝜑. 𝑃 (c (𝜑 z) (𝐹 (𝐵 𝜑 𝜑)) ⇒ 𝑃 (𝐹 𝜑)) | 𝑃 ∈ {𝑃𝑆 , 𝑃0, 𝑃1, 𝑃2, 𝑃3 }}
∪ {(∀𝜑 𝜓 𝑥 . 𝑃 (𝜑 (𝜓 𝑥)) ⇒ 𝑃 (𝐵 𝜑 𝜓 𝑥)) | 𝑃 ∈ {𝑃𝑆 , 𝑃0, 𝑃1, 𝑃2, 𝑃3 }}
∪ {𝑃 1 𝑧, 𝑃2 𝑧, 𝑃3 𝑧, (∀𝑥 𝑦. 𝑃 1 𝑥 ∧ 𝑃3 𝑥 ∧ 𝑃𝑆 𝑦 ⇒𝑃𝑆 (c 𝑥 𝑦))} ∪ {∀𝑥 . 𝑃𝑖 𝑥 ⇒𝑃𝑖+1 (s 𝑥) | 𝑖 ∈ [0..3]}
Definition 5.10 (Typing Algorithm). Given definite formula 𝐷, we construct a type environment
Γ ∞ (𝐷) = ΓV (𝐷) using the (inductive) MSL(𝜔) rewrite algorithm:
(∀𝑦. 𝐺 ⇒ 𝑃 (𝑓 𝑦)) ∈ 𝐷 Γ F Γ ∞ (𝐷)
𝑉Γ , 𝑦 ⊢ 𝐺 ⊲∗ 𝑈 𝑓 :: fromCl(∀𝑦. 𝑈 ⇒ 𝑃 (𝑓 𝑦)) ∈ Γ ∞ (𝐷)
Proof sketch. For Theorem 5.9, it suffices to show the following:
∃G-coconsistent Γ. Γ ⊢ 𝑡 :: 𝜏 if, and only if, V (𝐷 G ) ⊢ toCl(𝜏)(𝑡) ⊲∗ true
We rely on the correspondence between typing and rewriting (Proposition 5.6), and the fact that
Γ ∞ (𝐷 G ) = ΓV (𝐷 G ) is the largest G-coconsistent environment. The claim follows from the restricted
case where the LHS is ⊢ 𝑆 :: 𝑞 0 . □
The reduction from HORS untypeability to MSL(𝜔) provability is clearly polynomial. This gives
us a lower bound on the complexity of MSL(𝜔) in the order 𝑛 of the program and highest arity 𝑘 of
any function symbol, based on the known complexity of HORS untypeability.
Theorem 5.11. Deciding MSL(𝜔) provability is at least exp𝑛−1 (𝑘 |Π|)-hard.
6 We allow clauses toCl(𝜏) (𝑐) in 𝐷 G even though they are not generally definite clauses. Because they are automaton, we
could instead directly include them in the first iteration of the rewriting algorithm.
5.3 Reducing MSL(𝜔) to HORS Intersection Typing

For the converse reduction, we reduce MSL(𝜔) directly to HORS cotrivial automaton model checking.
We rely on an extension of HORS by Neatherway et al. [2012] called HORS with cases that enables
us to use nondeterminism and a case-switch on the base types 𝑄 𝜄 (i.e. predicates Π), due to MSL(𝜔)
lacking a clean separation between a state-agnostic rewrite system and a property automaton.
The MSL(𝜔) constants true and ∧ are encoded as a HORS constant and variable, resp., making
clause bodies monadic. Now a clause (∀𝑦. 𝑃 ′ 𝑡 ⇒ 𝑃 (𝑓 𝑦)) can be mapped to 𝑓 𝑦 𝑝 = 𝑡 𝑝 ′, where 𝑝 is
a constant corresponding to 𝑃 ∈ Π.
MSL(𝜔)-to-HORS Transformation. We transform MSL(𝜔) constructor types 𝛾 to HORS types 𝛾 +
by setting 𝜄 + := 𝜄 → 𝜄 and (𝛾 1 → 𝛾 2 ) + := 𝛾 1+ → 𝛾 2+ . Then, the goal transformation to HORS bodies
encodes true and ∧ as:
true+ := true (𝐺 ∧ 𝐻 ) + := 𝐺 + ∧ 𝐻 + (𝑃 𝑠) + := 𝑠 𝑃
where, by some abuse, true and ∧ on the RHS are a HORS constant and variable, resp.
MSL(𝜔)-as-HORS. Given an existential-free MSL(𝜔) definite formula 𝐷 0 and goal formula 𝐺 0
over Π and Σ, we construct the HORS G = ⟨Σcon, N, R, 𝑆⟩ defined by:
Σcon := {true : 𝜄} ∪ {𝑃 : 𝜄 → 𝑜 ∈ Π}
N := {𝑓 : 𝛾 + | 𝑓 : 𝛾 ∈ Σ} ∪ {𝑆 : 𝜄} ∪ {∧ : 𝜄 → 𝜄 → 𝜄}
R := {𝑓 𝑥 𝑃 = 𝐺 + | (∀𝑥 . 𝐺 ⇒ 𝑃 (𝑓 𝑥)) ∈ 𝐷 0 } ∪ {𝑆 = 𝐺 0+ } ∪ {∧ true true = true}
The Automaton. Because MSL(𝜔) does not have a clean separation between automaton and
state-agnostic definitions, our automaton is trivial; it consists of a single state that accepts only the
non-terminating/non-finished tree ⊥. Intuitively, 𝐺 0+ rewrites to true precisely if 𝐷 0 ⊨ 𝐺 0 .
Proposition 5.12. 𝐷 0 ⊨ 𝐺 0 if, and only if, JGK ∈ L (𝐴)
This provides the missing link for the following theorem.
Theorem 5.13. MSL(𝜔) provability and HORS (cotrivial) model checking are interreducible.
6 IMPLEMENTATION & APPLICATION

We have implemented a decision procedure for MSL(𝜔) satisfiability in Haskell. Recall that the full
HOMSL(𝜔) language reduces to this fragment, see Section 3. Our implementation incrementally
rewrites clause bodies towards automaton form according to the rewrite relation from Section 4,
using automaton clauses that have already been discovered. When a clause body is fully rewritten so
a clause is automaton, further rewrites may become possible in other clause bodies, which are then
reconsidered. It is therefore important to retain partially rewritten clauses. This procedure continues
until no more automaton clauses can be produced and the set of clauses has been saturated.
To assess the viability of our MSL(𝜔) decision procedure for higher-order verification, we study
the case of socket programming in Haskell, where higher-order constraints arise naturally from
the use of continuations in effectful code.
We implemented a Haskell library which provides an abstract typeclass of socket effects, one
instance of which generates constraints whose satisfiability implies correct usage of the sockets.
This approach alleviates the need for a heavyweight analysis front-end by exploiting a common
pattern of coding with effects. Typically, a program analysis front-end would take the source
code of the program as input, internalise it as an AST and then walk over the AST to generate
constraints; then a separate back-end would solve the constraints. Our approach instead allows
us to use a typeclass instance to generate constraints directly, without any need to process the
program AST. Doing this has practical advantages, because a standalone front-end usually requires
regular updating to stay in sync with the syntax of a constantly evolving programming language.
Socket API. Socket APIs require the user to adhere to a strict protocol where only certain opera-
tions are permitted in each state. Correctly tracking the state of sockets throughout a program can
be difficult, much like with lazy IO, and is often the source of bugs. Our implementation allows us
to track not a single resource (e.g. file handler or socket) but countably many!
A socket can be in one of the following states: Ready, Bound, Listen, Open, Closed. The primitives
modifying the state of a socket are summarised by the automaton in Figure 9. As these primitives
operate in the IO-monad, we encode them in an explicit continuation-passing style such that
each primitive takes a socket and a continuation as arguments. The socket and continuation are
individuals (i.e. type 𝜄), except in the case of Accept that also creates a new socket and thus has
a continuation of type 𝜄 → 𝜄. Each state is encoded as a predicate, with an additional Untracked
predicate whose meaning we explain below.
To account for the use of countably many resources, we employ a known trick that tracks the
state of just one resource and non-deterministically chooses whether to track a newly created
socket (unless one is already tracked) [Cook et al. 2007; Kobayashi 2013]. In our case, the fresh
socket is either (1) labelled 𝑠 and subsequent operations acting on it contribute to the overall state
or (2) labelled 𝑢 and is untracked. This approach suffices, because for each socket there exists a
branch in which its behaviour is tracked and incorrect usage violates the overall state.
The MSL(𝜔) Clauses. Given a socket-
manipulating Haskell program, the imple- accept
bind listen
mentation computes a two-part MSL(𝜔) Ready Bound Listen
formula that models its behaviour: (1) a

formula that captures the socket protocol
connect close
and (2) a clausal representation of the se- accept (create)
mantics of the program. Intuitively, a pred- send/receive

close
icate is satisfied by a program when that Open Close
program’s usage of the tracked socket vi-

olates the protocol for the corresponding
state. The Untracked predicate is satisfied Fig. 9. Socket states and operations manipulating them
by a program that violates the protocol for
any socket. When predicates are supplied with the tracked socket, the clauses encode the com-
plement of the automaton from Figure 9; otherwise the state is unchanged. Furthermore, when
sockets are created in the Untracked state, as described above, there are two clauses to account for
whether the new socket is to be tracked or not. If a socket is created in any other state, it is simply
untracked to prevent junk branches where multiple sockets are tracked with overlapping states.
Extracting Constraints. Part (2) the two-part MSL(𝜔) formula is determined by the program.
However, our approach does not need to process the Haskell source code and obtain an AST.
Instead, we rely on a Haskell typeclass instance.
The socket primitives are provided as methods of a typeclass refining the monad class, which is
further parametrised by the type of sockets. The instance of this typeclass for IO behaves in the
usual manner, but we also supply an instance for analysis whose sockets are variable names and
which merely accumulates the effects as raw syntax, ignoring any parameters other than the socket
and continuation.
The advantage of this approach is that processing the source code of the program is not required,
instead relying on normal, program evaluation to construct the constraints. One complication,
however, is that we require any unbounded recursion to be made explicit to prevent an infinite
evaluation of the program’s definition. We provide a method capturing this as part of the typeclass
interface. Recursion points are given a fresh name, to simulate as top-level definition of the program,
and their bodies are analysed and attributed to those function names. Once a collection of recursive
top-level definitions has been identified with an additional entry point we generate clauses unfolding
each definition, without changing state, as in Theorem 5.9.
Furthermore, the program cannot arbitrarily depend on runtime data such as the value received
by a socket; the effects of the program must be statically known. Branching code is not completely
precluded however. Inspired by the selective extension of applicative functors that supports finite
branching on runtime data, we add a branch combinator branch : Bool → 𝑓 𝑎 → 𝑓 𝑎 → 𝑓 𝑎,
encoded as multiple clauses that disregard the condition [Mokhov et al. 2019].
Examples. We tested our tool on example socket-manipulating programs taken from Stack
Overflow (with values modified). When presenting these examples, we will use Haskell’s do-
notation and the “bind” operators (≫, ≫=) for monadic actions as exposed in the user-interface,
which are to be understood as syntactic-sugar for the underlying continuation passing-style. The
first, with the original program on the left, violates the protocol on line 8 where it attempts to send
a message over soc which is in the Listening state after line 57 . The tool was able to correctly
detect the bug in 4.9ms, and accepted the correction (on the right) after 3.4ms.
1 main = do 1 main = do
2 soc ← socket 2 soc ← socket
3 bind soc 1234 3 bind soc 1234
4 listen soc 4 listen soc
5 x ← accept soc 5 x ← accept soc
6 forever $ do 6 forever $ do
7 receive x 7 receive x
8 send soc "Hi!" 8 send x "Hi!"
The following toy example makes use of our branching construct. When run in the IO monad,
this will behave just like an if −then−else clause. For analysis, however, both branches are explored.
The snippet initialises a socket and repeatedly receives a message until it is “close” when it closes
the socket. In the version on the left, the loop continues regardless, thus attempting to receive from
a closed socket. This implementation violates the protocol and is detected by our tool in 4.2ms. The
fix, on the right, exits the loop once the socket is closed and was accepted in 5.1ms.
1 main = do 1 main = do
2 soc ← socket 2 soc ← socket
3 bind soc 1234 3 bind soc 1234
4 listen soc 4 listen soc
5 x ← accept soc 5 x ← accept soc
6 forever $ do 6 fix $ \k → do
7 msg ← receive x 7 msg ← receive x
8 branch (msg == " close " ) 8 branch (msg == " close " )
9 ( close x) 9 ( close x >> k)
10 (pure ()) 10 (k ())
7 https://stackoverflow.com/q/62052147
7 CONCLUSION AND RELATED WORK

We have proposed new classes of constraints that are designed to capture the complex, higher-
order behaviours of programs with first-class procedures. We developed their theory to (a) show
decidability of the classes and (b) situate them with respect to higher-order program verification.
We also described an implementation and its application to the verification of socket programming.
Complexity. Our reduction of intersection typeability to MSL(𝜔) satisfiability gives us (𝑛 − 1)-

EXPTIME hardness of MSL(𝜔) satisfiability. Furthermore, the reduction of order-𝑛 MSL(𝜔) to
order-(𝑛 + 1) HORS with cases provides an (𝑛 + 1)-EXPTIME upper bound, thanks to a result
by Clairambault et al. [2018]. We derive this same naive upper bound directly from the decision
procedure, where every application of (Step) or (Assm) on an order-𝑛 symbol has 𝑛-exponentially
many candidate side conditions. Further study is required to obtain a tighter upper bound.
Related Work. We survey some of the work that is most closely related to our own.
Automata, Types, and Clauses. MSL was proposed independently by Weidenbach [1999] and
Nielson et al. [2002] (as H 1), with Goubault-Larrecq [2005] providing the bridge between the
two. Since then, it has been extended beyond Horn and with the addition of straight dismatching
constraints in Teucke and Weidenbach [2017]. Recall that the solved form of clauses for the first-
order H 1 fragment were named automaton clauses because of their shape, a connection that has
also been made in Nagaya and Toyama [2002]; Weidenbach [1999]. This name is equally justified for
our (higher-order) automaton clauses, since they, too, define finite tree automata [via intersection
types, Broadbent and Kobayashi 2013]. The relationship between higher-order automata, types,
and particular sets of clauses goes back to Frühwirth et al. [1997].
Set Constraints. Set constraints are a powerful language that has been very influential in program
analysis [Aiken 1999]. They are known to be equivalent to the monadic class [Bachmair et al. 1993]
and, therefore, have a very close connection with MSL. Higher-order set constraints have also been
considered, defining sets of terms rather than higher-order predicates much like MSL(𝜔) [Goubault-
Larrecq 2002]. Although the relationship between our constraints and those of loc cit is not well
understood, we point out that their constraints are solvable in 2-NEXPTIME, whereas satisfiability
in our class is (𝑛 − 1)-EXPTIME hard.
HORS Model Checking. There is a strong connection between traditional higher-order model
checking with higher-order recursion schemes [e.g. Kobayashi 2013] and MSL(𝜔) problems, as
witnessed by their interreducibility. Many approaches to inferring and verifying types for higher-
order recursion schemes have been considered, but the most closely related to our work is the
saturation-based approach considered by Broadbent and Kobayashi [2013]. The main novelty
of their algorithm is that typing constraints are propagated backwards starting from the final
(unaccepted) states, rather than the forward from the target state. While backward propagation
is analogous to goal-orientation search, attempting to derive clauses in order to rewrite the goal,
their saturation-based approach is similar to our accumulation of automaton clauses in a bottom-
up manner. Furthermore, follow-up work improved upon the efficiency of the saturation-based
approach by representing intersection types as a type of binary decision diagrams that compactly
describes a family of sets [Terao and Kobayashi 2014]. More work needs to be done to draw a detailed
comparison between these algorithms and our own. Furthermore, as many of these algorithms are
in their second or third generation, there will be possible optimisations that can be transferred to
our own setting, in addition to novel optimisations that take advantage of our setting.
HFL Model Checking. Higher-order fixpoint logic, HFL, is a very expressive logic also designed
as an appropriate language for program verification [Kobayashi 2021]. It is more expressive than
higher-order (constrained) Horn clauses in general, and our fragment in particular, by supporting
both the greatest and least fixpoint. This duality allows it to express liveness properties as well as
safety properties. Furthermore, this logic allows for a background constraint theory. In the pure
case, HFL is known to be decidable by reduction to intersection typing problem [Hosoi et al. 2019].
Refinement Type Checking and Constrained Horn Clauses. It was observed by Grebenshchikov et al.
[2012] that a standard approach taken to solving refinement type inference problems, such as Jhala
et al. [2011]; Terauchi [2010]; Unno and Kobayashi [2009], is essentially a reduction to constrained
Horn clause solving. Although only first order, these systems of constraints are extremely expressive
since they incorporate an arbitrary background theory, such as linear arithmetic or the theory of
algebraic datatypes. Consequently, they are typically undecidable. Constrained Horn clauses were
lifted to higher order by Cathcart Burn et al. [2017], and the theory further explored in Ong and
Wagner [2019]. In a follow-up work the same authors identified a family of decidable fragments
intended for applications in database aggregation [Cathcart Burn et al. 2021].
Uniform Proofs and Logic Programming. The formulation of our fragments and the proof system
that underlies them follows the elegant presentation in the work of Miller and his collaborators,
such as Miller and Nadathur [2012]; Miller et al. [1991]. In particular, one can recognise their fohc,
hohc, and hohh as the underlying formalisms behind our MSL(1) clauses, HOMSL(𝜔) clauses, and
higher-order automaton clauses respectively. Of course, we could have presented our fragments of
HOL in a more traditional format for automated reasoning (e.g. with clauses as multisets of literals),
but we consider the compositional characterisation that is characteristic of Miller’s work essential
for a clear exposition once we have to deal with the combination of nested clauses (in the sense of
hereditary Harrop) and higher-order constructs.
Constructive Logic and ‘Horn Clauses as Types’. Over a series of papers, Fu, Komendantskaya, and
co-authors have presented a comprehensive analysis of Horn clauses and resolution according to the
propositions-as-types tradition [Farka 2020; Fu and Komendantskaya 2015, 2017; Fu et al. 2016]. Like
our work, they cast resolution as a form of rewriting, studying a number of different variations on
the standard approach that have been motivated by the desire to capture computations with infinite
data. Using Howard’s System H [Howard 1980], they give a type-theoretic semantics to each form
of resolution, and this allows for a more meaningful notion of soundness and completeness than the
traditional method using Herbrand models. Since it is in the propositions-as-types tradition, their
work views a Horn clause as the type of its proofs. By contrast, we view an automaton clause with
a single free variable 𝑥 as a type inhabited by the terms that satisfy the clause (when substituted
for 𝑥). Consequently, we do not make use of the constructive content of the resolution proofs
themselves, but rather view resolution simply as a mechanism for generating a new clause from
two given clauses – i.e. a way to infer new types.
ACKNOWLEDGMENTS
We gratefully acknowledge the support of the Engineering and Physical Sciences Research Council
(EP/T006595/1) and the National Centre for Cyber Security via the UK Research Institute in Verified
Trustworthy Software Systems. We are also very grateful for the help of the reviewers in making
the paper more clear and accurate, and for suggesting related work.
REFERENCES
Alexander Aiken. 1999. Introduction to set constraint-based program analysis. Science of Computer Programming 35, 2
(1999), 79–111. https://doi.org/10.1016/S0167-6423(99)00007-6
Leo Bachmair, Harald Ganzinger, and Uwe Waldmann. 1993. Set Constraints are the Monadic Class. In Eighth Annual IEEE
Symposium on Logic in Computer Science. IEEE, Montreal, Canada, 75–83. https://doi.org/10.1109/LICS.1993.287598
Christopher Broadbent and Naoki Kobayashi. 2013. Saturation-based model checking of higher-order recursion schemes.
In Computer Science Logic 2013 (CSL 2013). Schloss Dagstuhl-Leibniz-Zentrum für Informatik. https://doi.org/10.4230/
LIPIcs.CSL.2013.129
Florian Bruse, Martin Lange, and Étienne Lozes. 2021. The Complexity of Model-Checking Tail-Recursive Higher-Order
Fixpoint Logic. Fundam. Informaticae 178, 1-2 (2021), 1–30. https://doi.org/10.3233/FI-2021-1996
Toby Cathcart Burn, C.-H. Luke Ong, and Steven J. Ramsay. 2017. Higher-Order Constrained Horn Clauses for Verification.
Proc. ACM Program. Lang. 2, POPL, Article 11 (Dec 2017), 28 pages. https://doi.org/10.1145/3158099
Toby Cathcart Burn, C.-H. Luke Ong, Steven J. Ramsay, and Dominik Wagner. 2021. Initial Limit Datalog: a New Extensible
Class of Decidable Constrained Horn Clauses. In 2021 36th Annual ACM/IEEE Symposium on Logic in Computer Science
(LICS). 1–13. https://doi.org/10.1109/LICS52264.2021.9470527
Angelos Charalambidis, Christos Nomikos, and Panos Rondogiannis. 2019. The Expressive Power of Higher-Order Datalog.
Theory and Practice of Logic Programming 19, 5-6 (2019), 925–940. https://doi.org/10.1017/S1471068419000279
Pierre Clairambault, Charles Grellois, and Andrzej S. Murawski. 2018. Linearity in Higher-Order Recursion Schemes. Proc.
ACM Program. Lang. 2, POPL, Article 39 (Dec 2018), 29 pages. https://doi.org/10.1145/3158127
Byron Cook, Alexey Gotsman, Andreas Podelski, Andrey Rybalchenko, and Moshe Y Vardi. 2007. Proving that programs
eventually do something good. ACM SIGPLAN Notices 42, 1 (2007), 265–276. https://doi.org/10.1145/1190216.1190257
František Farka. 2020. Proof-Relevant Resolution: the Foundations of Constructive Proof Automation. Ph. D. Dissertation.
Heriot-Watt University, UK.
Thom Frühwirth, Moshe Vardi, and Eyal Yardeni. 1997. Logic Programs as Types for Logic Programs. Proceedings –
Symposium on Logic in Computer Science (12 1997). https://doi.org/10.1109/LICS.1991.151654
Peng Fu and Ekaterina Komendantskaya. 2015. A Type-Theoretic Approach to Resolution. In Logic-Based Program Synthesis
and Transformation, Moreno Falaschi (Ed.). Springer International Publishing, Cham, 91–106. https://doi.org/10.1007/978-
3-319-27436-2_6
Peng Fu and Ekaterina Komendantskaya. 2017. Operational Semantics of Resolution and Productivity in Horn Clause Logic.
Form. Asp. Comput. 29, 3 (may 2017), 453–474. https://doi.org/10.1007/s00165-016-0403-1
Peng Fu, Ekaterina Komendantskaya, Tom Schrijvers, and Andrew Pond. 2016. Proof Relevant Corecursive Resolution.
In Functional and Logic Programming, Oleg Kiselyov and Andy King (Eds.). Springer International Publishing, Cham,
126–143. https://doi.org/10.1007/978-3-319-29604-3_9
Jean Goubault-Larrecq. 2002. Higher-Order Positive Set Constraints. In Computer Science Logic, Julian Bradfield (Ed.).
Springer Berlin Heidelberg, Berlin, Heidelberg, 473–489. https://doi.org/10.1007/3-540-45793-3_32
Jean Goubault-Larrecq. 2005. Deciding H1 by resolution. Inform. Process. Lett. 95, 3 (2005), 401–408. https://doi.org/10.
1016/j.ipl.2005.04.007
Sergey Grebenshchikov, Nuno P. Lopes, Corneliu Popeea, and Andrey Rybalchenko. 2012. Synthesizing Software Veri-
fiers from Proof Rules. In Proceedings of the 33rd ACM SIGPLAN Conference on Programming Language Design and
Implementation (Beijing, China) (PLDI ’12). Association for Computing Machinery, New York, NY, USA, 405–416.
https://doi.org/10.1145/2254064.2254112
Matthew Hague, Andrzej S. Murawski, C.-H. Luke Ong, and Olivier Serre. 2008. Collapsible Pushdown Automata and
Recursion Schemes. In Logic in Computer Science, LICS’08. IEEE Computer Society, 452–461.
Haskell.org. 2013. Iteratee I/O: The problem with lazy IO. Retrieved 7 July 2022 from https://wiki.haskell.org/Iteratee_I/O#
The_problem_with_lazy_I.2FO
Youkichi Hosoi, Naoki Kobayashi, and Takeshi Tsukada. 2019. A type-based HFL model checking algorithm. In Asian
Symposium on Programming Languages and Systems. Springer, 136–155. https://doi.org/10.1007/978-3-030-34175-6_8
William Howard. 1980. The formulae-as-types notion of construction. In To H. B. Curry: Essays on Combinatory Logic,
Lambda Calculus and Formalism, J. Seldin and R. J. Hindley (Eds.). Academic Press.
Ranjit Jhala, Rupak Majumdar, and Andrey Rybalchenko. 2011. HMC: Verifying Functional Programs Using Abstract
Interpreters. In Computer Aided Verification, Ganesh Gopalakrishnan and Shaz Qadeer (Eds.). Springer Berlin Heidelberg,
Berlin, Heidelberg, 470–485. https://doi.org/10.1007/978-3-642-22110-1_38
Jerome. Jochems. 2020. Higher-order constrained Horn clauses for higher-order program verification. Ph. D. Dissertation.
Oxford University, UK.
Jerome Jochems, Eddie Jones, and Steven Ramsay. 2022. Higher-Order MSL Horn Constraints. https://doi.org/10.48550/
ARXIV.2210.14649
Naoki Kobayashi. 2009. Types and Higher-Order Recursion Schemes for Verification of Higher-Order Programs. SIGPLAN
Not. 44, 1 (Jan 2009), 416–428. https://doi.org/10.1145/1594834.1480933
Naoki Kobayashi. 2013. Model checking higher-order programs. Journal of the ACM (JACM) 60, 3 (2013), 1–62. https:
//doi.org/10.1145/2487241.2487246
Naoki Kobayashi. 2021. An Overview of the HFL Model Checking Project. arXiv preprint arXiv:2109.04629 (2021). https:
//doi.org/10.4204/EPTCS.344.1
Naoki Kobayashi and C.-H. Luke Ong. 2009. A Type System Equivalent to the Modal Mu-Calculus Model Checking of
Higher-Order Recursion Schemes. In Logic in Computer Science, LICS 2009. IEEE Computer Society, 179–188. https:
//doi.org/10.1109/LICS.2009.29
Dale Miller and Gopalan Nadathur. 2012. Programming with Higher-Order Logic. Cambridge University Press. https:
//doi.org/10.1017/CBO9781139021326
Dale Miller, Gopalan Nadathur, Frank Pfenning, and Andre Scedrov. 1991. Uniform proofs as a foundation for logic
programming. Annals of Pure and Applied Logic 51, 1 (1991), 125–157. https://doi.org/10.1016/0168-0072(91)90068-W
Andrey Mokhov, Georgy Lukyanov, Simon Marlow, and Jeremie Dimino. 2019. Selective applicative functors. Proceedings of
the ACM on Programming Languages 3, ICFP (2019), 1–29. https://doi.org/10.1145/3341694
David E. Muller and Paul E. Schupp. 1987. Alternating automata on infinite trees. Theoretical Computer Science 54, 2 (1987),
267–276. https://doi.org/10.1016/0304-3975(87)90133-2
Takashi Nagaya and Yoshihito Toyama. 2002. Decidability for Left-Linear Growing Term Rewriting Systems. Information
and Computation 178, 2 (2002), 499–514. https://doi.org/10.1006/inco.2002.3157
Robin P. Neatherway, Steven J. Ramsay, and C.-H. Luke Ong. 2012. A Traversal-Based Algorithm for Higher-Order Model
Checking. SIGPLAN Not. 47, 9 (Sep 2012), 353–364. https://doi.org/10.1145/2398856.2364578
Flemming Nielson, Hanne Riis Nielson, and Helmut Seidl. 2002. Normalizable Horn clauses, strongly recognizable relations,
and Spi. In International Static Analysis Symposium. Springer, 20–35. https://doi.org/10.1007/3-540-45789-5_5
C.-H. Luke Ong. 2006. On Model-Checking Trees Generated by Higher-Order Recursion Schemes. In 21th IEEE Symposium
on Logic in Computer Science (LICS 2006), 12-15 August 2006, Seattle, WA, USA, Proceedings. 81–90. https://doi.org/10.
1109/LICS.2006.38
C.-H. Luke Ong and Dominik Wagner. 2019. HoCHC: A Refutationally Complete and Semantically Invariant System of
Higher-order Logic Modulo Theories. In 2019 34th Annual ACM/IEEE Symposium on Logic in Computer Science (LICS).
1–14. https://doi.org/10.1109/LICS.2019.8785784
Steven J. Ramsay, Robin P. Neatherway, and C.-H. Luke Ong. 2014. A Type-Directed Abstraction Refinement Approach to
Higher-Order Model Checking. In Principles of Programming Languages, POPL’14. ACM, 61–72. https://doi.org/10.1145/
2535838.2535873
Jakob Rehof and Paweł Urzyczyn. 2011. Finite Combinatory Logic with Intersection Types. In Typed Lambda Calculi and
Applications, C.-H. Luke Ong (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 169–183. https://doi.org/10.1007/978-
3-642-21691-6_15
Patrick Maxim Rondon, Ming Kawaguchi, and Ranjit Jhala. 2008. Liquid types. In Proceedings of the ACM SIGPLAN
2008 Conference on Programming Language Design and Implementation, Tucson, AZ, USA, June 7-13, 2008. 159–169.
Sylvain Salvati and Igor Walukiewicz. 2016. Simply typed fixpoint calculus and collapsible pushdown automata. Math.
Struct. Comput. Sci. 26, 7 (2016), 1304–1350. https://doi.org/10.1017/S0960129514000590
Taku Terao and Naoki Kobayashi. 2014. A ZDD-based efficient higher-order model checking algorithm. In Asian Symposium
on Programming Languages and Systems. Springer, 354–371. https://doi.org/10.1007/978-3-319-12736-1_19
Tachio Terauchi. 2010. Dependent types from counterexamples. In Proceedings of the 37th ACM SIGPLAN-SIGACT Symposium
on Principles of Programming Languages, POPL 2010, Madrid, Spain, January 17-23, 2010. 119–130. https://doi.org/10.
1145/1706299.1706315
Andreas Teucke and Christoph Weidenbach. 2017. Decidability of the Monadic Shallow Linear First-Order Fragment with
Straight Dismatching Constraints. In Automated Deduction – CADE 26, Leonardo de Moura (Ed.). Springer International
Publishing, Cham, 202–219. https://doi.org/10.1007/978-3-319-63046-5_13
Hiroshi Unno and Naoki Kobayashi. 2009. Dependent type inference with interpolants. In Proceedings of the 11th International
ACM SIGPLAN Conference on Principles and Practice of Declarative Programming, September 7-9, 2009, Coimbra, Portugal.
277–288. https://doi.org/10.1145/1599410.1599445
Niki Vazou, Alexander Bakst, and Ranjit Jhala. 2015. Bounded refinement types. In Proceedings of the 20th ACM SIGPLAN
International Conference on Functional Programming, ICFP 2015, Vancouver, BC, Canada, September 1-3, 2015. 48–61.
Niki Vazou, Patrick Maxim Rondon, and Ranjit Jhala. 2013. Abstract Refinement Types. In Programming Languages and
Systems - 22nd European Symposium on Programming, ESOP 2013, Held as Part of the European Joint Conferences on Theory
and Practice of Software, ETAPS 2013, Rome, Italy, March 16-24, 2013. Proceedings. 209–228. https://doi.org/10.1007/978-3-
642-37036-6_13
Mahesh Viswanathan and Ramesh Viswanathan. 2004. A Higher Order Modal Fixed Point Logic. In CONCUR 2004 -
Concurrency Theory, Philippa Gardner and Nobuko Yoshida (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg,
512–528. https://doi.org/10.1007/978-3-540-28644-8_33
Christoph Weidenbach. 1999. Towards an Automatic Analysis of Security Protocols in First-Order Logic. In Automated
Deduction — CADE-16. Springer Berlin Heidelberg, Berlin, Heidelberg, 314–328. https://doi.org/10.1007/3-540-48660-7_29
He Zhu and Suresh Jagannathan. 2013. Compositional and Lightweight Dependent Type Inference for ML. In Verification,
Model Checking, and Abstract Interpretation, 14th International Conference, VMCAI 2013, Rome, Italy, January 20-22, 2013.
Proceedings. 295–314. https://doi.org/10.1007/978-3-642-35873-9_19
Received 2022-07-07; accepted 2022-11-07

Higher-Order MSL Horn Constraints: Jerome Jochems, Eddie Jones, Steven Ramsay

Uploaded by

Copyright:

Available Formats

Higher-Order MSL Horn Constraints: Jerome Jochems, Eddie Jones, Steven Ramsay

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Higher-Order MSL Horn Constraints: Jerome Jochems, Eddie Jones, Steven Ramsay

Uploaded by

Copyright:

Available Formats

Higher-Order MSL Horn Constraints

JEROME JOCHEMS, University of Bristol, UK

1.1 MSL Horn Constraints

1.2 Contributions of this Paper

1.3 Wider Significance

However, higher-order automated program verification comprises a disparate collection of

(Var) 𝑥 :𝜏 ∈ Δ (Cst) 𝑐 :𝛾 ∈ Σ (Pred) 𝑃 :𝜌 ∈Π

Fig. 1. Typing of terms, goals and clauses

2 HIGHER-ORDER MSL HORN FORMULAS

Fig. 2. Proof system for goal formulas

2.1 Proof System and Decision Problems

2.2 Stratification by Type-Theoretic Order

2.3 Example: Constraints for Lazy IO

𝑝 [] ⇒ Ex 𝑝 (1) Closed(ℎ) ⇒ V(read ℎ 𝑘) (7)

Fig. 3. Clauses corresponding to the verification of Example 2.3

Fig. 4. Proof in the environment given by Figure 3

PQ 𝑥 ⇒S𝑥 T(p q 𝑥) ⇒ T(s 𝑥) R(a c)

3 FROM HOMSL(𝜔) TO EXISTENTIAL-FREE MSL(𝜔)

3.1 Elimination of Higher-Order Predicates

3.2 Elimination of Existentials

2 the clause head is Comp0,𝑛 𝑣 when 𝑖 = 0

4 HIGHER-ORDER AUTOMATON CLAUSES AND THE DECISION PROCEDURE

4.1 Higher-Order Resolution

3 Negative literals with depth 0 are essentially already solved.

(Fact1 ) 𝑐:𝜄 ∈ Σ (Fact2 )

Fig. 7. Typing for automaton clauses and formulas

4.2 Higher-Order Automaton Formulas

4.3 Decision Procedure

𝑃𝑥 ∈𝑉 (Refl) (∀𝑥 . 𝑈 ⇒ 𝑃 (𝑓 𝑥)) ∈ 𝑉 (Step)

(∀𝑥𝑧. 𝑈 ⇒ 𝑃 (𝑓 𝑥𝑧)) ∈ 𝑉 (Assm)

Fig. 8. Rewrite system

4.4 Rewriting Example

V(𝑥 ℎ (putCont 𝑘)) ⊲ Closed(ℎ) ∧ (∀ℎ 𝑘. Closed(ℎ) ⇒ V (𝑥 ℎ 𝑘))

From this, we obtain (10’): Closed(ℎ) ∧ (∀ℎ 𝑘. Closed(ℎ) ⇒ V (𝑥 ℎ 𝑘)) ⇒ V(putStrLn 𝑥 ℎ 𝑘) is an

V(putStrLn 𝑥 ℎ 3 id) ⊲ Closed(ℎ 3 ) ∧ (∀ℎ 𝑘. Closed(ℎ) ⇒ V (𝑥 ℎ 𝑘))

Closed(ℎ 2 ) ∧ (∀ℎ 𝑘. Closed(ℎ) ⇒ V (𝑦 ℎ 𝑘))

5 AUTOMATON CLAUSES: CONNECTING LOGIC, TYPES, AND AUTOMATA

5.1 Correspondence with Intersection Types

Example 5.2. Let 𝑈 = ∀𝑣 𝑥 𝑦. 𝑄 𝑦 ∧ (∀𝑧. 𝑄 𝑧 ∧ 𝑃 𝑧 ⇒ 𝑅 (𝑥 𝑧)) ⇒ 𝑃 (𝑐 𝑣 𝑥 𝑦). The following hold:

This is witnessed by:

Lemma 5.3 (Order isomorphism). Let 𝜃, 𝜃 1, 𝜃 2 be intersection types of type 𝜎1 → · · · → 𝜎𝑚 → 𝜄

Π𝑄 := {𝑃 | 𝑞𝑃 ∈ 𝑄 } 𝑉Σ,Γ := {toCl(type(𝑓 ))(𝑓 ) | 𝑓 ∈ Σ} ∪ {toCl(𝜃 )(𝑎) | 𝑎 :: 𝜃 ∈ Γ}

Lemma 5.5. 𝑉Γ𝑉 = 𝑉 and Γ𝑉Γ = Γ.

5.2 Reducing HORS Intersection Typing to MSL(𝜔)

5.3 Reducing MSL(𝜔) to HORS Intersection Typing

6 IMPLEMENTATION & APPLICATION

formula that models its behaviour: (1) a

mantics of the program. Intuitively, a pred- send/receive

program’s usage of the tracked socket vi-

7 CONCLUSION AND RELATED WORK

Complexity. Our reduction of intersection typeability to MSL(𝜔) satisfiability gives us (𝑛 − 1)-

Received 2022-07-07; accepted 2022-11-07

You might also like