HigherOrder Program Verification via HFL Model Checking
Abstract
There are two kinds of higherorder extensions of model checking: HORS model checking and HFL model checking. Whilst the former has been applied to automated verification of higherorder functional programs, applications of the latter have not been well studied. In the present paper, we show that various verification problems for functional programs, including may/mustreachability, trace properties, and lineartime temporal properties (and their negations), can be naturally reduced to (extended) HFL model checking. The reductions yield a sound and complete logical characterization of those program properties. Compared with the previous approaches based on HORS model checking, our approach provides a more uniform, streamlined method for higherorder program verification.
1 Introduction
There are two kinds of higherorder extensions of model checking in the literature: HORS model checking [16, 32] and HFL model checking [42]. The former is concerned about whether the tree generated by a given higherorder tree grammar called a higherorder recursion scheme (HORS) satisfies the property expressed by a given modal \(\mu \)calculus formula (or a tree automaton), and the latter is concerned about whether a given finite state system satisfies the property expressed by a given formula of higherorder modal fixpoint logic (HFL), a higherorder extension of the modal \(\mu \)calculus. Whilst HORS model checking has been applied to automated verification of higherorder functional programs [17, 18, 22, 26, 33, 41, 43], there have been few studies on applications of HFL model checking to program/system verification. Despite that HFL has been introduced more than 10 years ago, we are only aware of applications to assumeguarantee reasoning [42] and process equivalence checking [28].
In the present paper, we show that various verification problems for higherorder functional programs can actually be reduced to (extended) HFL model checking in a rather natural manner. We briefly explain the idea of our reduction below.^{1} We translate a program to an HFL formula that says “the program has a valid behavior” (where the validity of a behavior depends on each verification problem). Thus, a program is actually mapped to a property, and a program property is mapped to a system to be verified; this has been partially inspired by the recent work of Kobayashi et al. [19], where HORS model checking problems have been translated to HFL model checking problems by switching the roles of models and properties.
We generalize the above idea and formalize reductions from various classes of verification problems for simplytyped higherorder functional programs with recursion, integers and nondeterminism – including verification of may/mustreachability, trace properties, and lineartime temporal properties (and their negations) – to (extended) HFL model checking where HFL is extended with integer predicates, and prove soundness and completeness of the reductions. Extended HFL model checking problems obtained by the reductions are (necessarily) undecidable in general, but for finitedata programs (i.e., programs that consist of only functions and data from finite data domains such as Booleans), the reductions yield pure HFL model checking problems, which are decidable [42].
Our reductions provide sound and complete logical characterizations of a wide range of program properties mentioned above. Nice properties of the logical characterizations include: (i) (like verification conditions for Hoare triples,) once the logical characterization is obtained as an HFL formula, purely logical reasoning can be used to prove or disprove it (without further referring to the program semantics); for that purpose, one may use theorem provers with various degrees of automation, ranging from interactive ones like Coq, semiautomated ones requiring some annotations, to fully automated ones (though the latter two are yet to be implemented), (ii) (unlike the standard verification condition generation for Hoare triples using invariant annotations) the logical characterization can automatically be computed, without any annotations,^{3} (iii) standard logical reasoning can be applied based on the semantics of formulas; for example, coinduction and induction can be used for proving \(\nu \) and \(\mu \)formulas respectively, and (iv) thanks to the completeness, the set of program properties characterizable by HFL formula is closed under negations; for example, from a formula characterizing mayreachability, one can obtain a formula characterizing nonreachability by just taking the De Morgan dual.
Compared with previous approaches based on HORS model checking [18, 22, 26, 33, 37], our approach based on (extended) HFL model checking provides more uniform, streamlined methods for higherorder program verification. HORS model checking provides sound and complete verification methods for finitedata programs [17, 18], but for infinitedata programs, other techniques such as predicate abstraction [22] and program transformation [27, 31] had to be combined to obtain sound (but incomplete) reductions to HORS model checking. Furthermore, the techniques were different for each of program properties, such as reachability [22], termination [27], nontermination [26], fair termination [31], and fair nontermination [43]. In contrast, our reductions are sound and complete even for infinitedata programs. Although the obtained HFL model checking problems are undecidable in general, the reductions allow us to treat various program properties uniformly; all the verifications are boiled down to the issue of how to prove \(\mu \) and \(\nu \)formulas (and as remarked above, we can use induction and coinduction to deal with them). Technically, our reduction to HFL model checking may actually be considered an extension of HORS model checking in the following sense. HORS model checking algorithms [21, 32] usually consist of two phases, one for computing a kind of higherorder “procedure summaries” in the form of variable profiles [32] or intersection types [21], and the other for nested least/greatest fixpoint computations. Our reduction from program verification to extended HFL model checking (the reduction given in Sect. 7, in particular) can be regarded as an extension of the first phase to deal with infinite data domains, where the problem for the second phase is expressed in the form of extended HFL model checking: see [23] for more details.
The rest of this paper is structured as follows. Section 2 introduces HFL extended with integer predicates and defines the HFL model checking problem. Section 3 informally demonstrates some examples of reductions from program verification problems to HFL model checking. Section 4 introduces a functional language used to formally discuss the reductions in later sections. Sections 5, 6, and 7 consider may/mustreachability, trace properties, and temporal properties respectively, and present (sound and complete) reductions from verification of those properties to HFL model checking. Section 8 discusses related work, and Sect. 9 concludes the paper. Proofs are found in an extended version [23].
2 (Extended) HFL
In this section, we introduce an extension of higherorder modal fixpoint logic (HFL) [42] with integer predicates (which we call HFL\(_{\mathbf {Z}}\); we often drop the subscript and write HFL, as in Sect. 1), and define the HFL\(_{\mathbf {Z}}\) model checking problem. The set of integers can actually be replaced by another infinite set \(X\) of data (like the set of natural numbers or the set of finite trees) to yield HFL\(_{X}\).
2.1 Syntax
For a map \(f\), we write \( dom (f)\) and \( codom (f)\) for the domain and codomain of \(f\) respectively. We write \(\mathbf {Z}\) for the set of integers, ranged over by the metavariable \(n\) below. We assume a set \(\mathbf {Pred}\) of primitive predicates on integers, ranged over by \(p\). We write \(\mathtt {arity}(p)\) for the arity of \(p\). We assume that \(\mathbf {Pred}\) contains standard integer predicates such as \(=\) and <, and also assume that, for each predicate \(p\in \mathbf {Pred}\), there also exists a predicate \(\lnot p\in \mathbf {Pred}\) such that, for any integers \(n_1,\ldots ,n_k\), \(p(n_1,\ldots ,n_k)\) holds if and only if \(\lnot p(n_1,\ldots ,n_k)\) does not hold; thus, \(\lnot p(n_1,\ldots ,n_k)\) should be parsed as \((\lnot p)(n_1,\ldots ,n_k)\), but can semantically be interpreted as \(\lnot (p(n_1,\ldots ,n_k))\).
We explain the meaning of each formula informally; the formal semantics is given in Sect. 2.2. Like modal \(\mu \)calculus [10, 25], each formula expresses a property of a labeled transition system. The first line of the syntax of formulas consists of the standard constructs of predicate logics. On the second line, as in the standard modal \(\mu \)calculus, \(\langle {a}\rangle \varphi \) means that there exists an \(a\)labeled transition to a state that satisfies \(\varphi \). The formula \([a]\varphi \) means that after any \(a\)labeled transition, \(\varphi \) is satisfied. The formulas \(\mu X^{\tau }.\varphi \) and \(\nu X^{\tau }.\varphi \) represent the least and greatest fixpoints respectively (the least and greatest \(X\) that \(X=\varphi \)) respectively; unlike the modal \(\mu \)calculus, \(X\) may range over not only propositional variables but also higherorder predicate variables (of type \(\tau \)). The \(\lambda \)abstractions \(\lambda X\mathbin {:}{\sigma }.\varphi \) and applications \(\varphi _1\; \varphi _2\) are used to manipulate higherorder predicates. We often omit type annotations in \(\mu X^{\tau }.\varphi \), \(\nu X^{\tau }.\varphi \) and \(\lambda X\mathbin {:}{\sigma }.\varphi \), and just write \(\mu X.\varphi \), \(\nu X.\varphi \) and \(\lambda X.\varphi \).
Example 1
2.2 Semantics and HFL\(_{\mathbf {Z}}\) Model Checking
We now define the formal semantics of HFL\(_{\mathbf {Z}}\) formulas. A labeled transition system (LTS) is a quadruple \(\mathtt {L}= (U{}, A{}, \mathbin {\mathbin {\longrightarrow }}, \mathtt {s}_\mathtt {init})\), where \(U{}\) is a finite set of states, \(A{}\) is a finite set of actions, \(\mathbin {\mathbin {\longrightarrow }} \subseteq U{}\times A{}\times U\) is a labeled transition relation, and \(\mathtt {s}_\mathtt {init}\in U\) is the initial state. We write \(\mathtt {s}_1{\mathop {\mathbin {\longrightarrow }}\limits ^{a}}\mathtt {s}_2\) when \((\mathtt {s}_1,a,\mathtt {s}_2)\in \mathbin {\longrightarrow }\).
Example 2
and \(\varphi _{\mathtt {ab}}\,(\langle {c}\rangle \mathbf {true})\) where \(\varphi _{\mathtt {ab}}\) is the one introduced in Example 1. Then, \(\llbracket \varphi _{\mathtt {ab}}\,(\langle {c}\rangle \mathbf {true}) \rrbracket _{\mathtt {L}_1} = \{q_0,q_2\}\).
Definition 1
( \(\mathbf{HFL}_\mathbf{Z}\) model checking). For a closed formula \(\varphi \) of type \(\bullet \), we write \(\mathtt {L}, \mathtt {s}\models \varphi \) if \(\mathtt {s}\in \llbracket \varphi \rrbracket _{\mathtt {L}}\), and write \(\mathtt {L}\models \varphi \) if \(\mathtt {s}_\mathtt {init}\in \llbracket \varphi \rrbracket _{\mathtt {L}}\). \(\mathrm{HFL}_\mathbf{Z}\) model checking is the problem of, given \(\mathtt {L}\) and \(\varphi \), deciding whether \(\mathtt {L}\models \varphi \) holds.
The HFL\(_{\mathbf {Z}}\) model checking problem is undecidable, due to the presence of integers; in fact, the semantic domain \(\mathcal {D}_{\mathtt {L},\sigma }\) is not finite for \(\sigma \) that contains \(\mathtt {int}\). The undecidability is obtained as a corollary of the soundness and completeness of the reduction from the mayreachability problem to HFL model checking discussed in Sect. 5. For the fragment of pure HFL (i.e., HFL\(_{\mathbf {Z}}\) without integers, which we write HFL\(_{\emptyset }\) below), the model checking problem is decidable [42].
The order of an HFL\(_{\mathbf {Z}}\) model checking problem \(\mathtt {L}{\mathop {\models }\limits ^{?}}\varphi \) is the highest order of types of subformulas of \(\varphi \), where the order of a type is defined by: \(\mathtt {order}(\bullet )=\mathtt {order}(\mathtt {int}) = 0\) and \(\mathtt {order}(\sigma \rightarrow \tau ) = \max (\mathtt {order}(\sigma )+1,\mathtt {order}(\tau ))\). The complexity of order\(k\) HFL\(_{\emptyset }\) model checking is \(k\)EXPTIME complete [1], but polynomial time in the size of HFL formulas under the assumption that the other parameters (the size of LTS and the largest size of types used in formulas) are fixed [19].
Remark 1
Though we do not have quantifiers on integers as primitives, we can encode them using fixpoint operators. Given a formula \(\varphi :\mathtt {int}\rightarrow \bullet \), we can express \(\exists x\mathbin {:}\mathtt {int}.\varphi (x)\) and \(\forall x\mathbin {:}\mathtt {int}.\varphi (x)\) by \((\mu X^{\mathtt {int}\rightarrow \bullet }.\lambda x\mathbin {:}\mathtt {int}.\varphi (x)\vee X(x1)\vee X(x+1))0\) and \((\nu X^{\mathtt {int}\rightarrow \bullet }.\lambda x\mathbin {:}\mathtt {int}.\varphi (x)\wedge X(x1)\wedge X(x+1))0\) respectively.
2.3 HES
As in [19], we often write an HFL\(_{\mathbf {Z}}\) formula as a sequence of fixpoint equations, called a hierarchical equation system (HES).
Definition 2
An (extended) hierarchical equation system (HES) is a pair \((\mathcal {E},\varphi )\) where \(\mathcal {E}\) is a sequence of fixpoint equations, of the form: \( X_1^{\tau _1} =_{\alpha _1} \varphi _1; \cdots ; X_n^{\tau _n} =_{\alpha _n} \varphi _n \), where \(\alpha _i\in \{\mu ,\nu \}\). We assume that \(X_1\mathbin {:}\tau _1,\ldots ,X_n\mathbin {:}\tau _n \vdash _{\mathtt {H}}\varphi _i:\tau _i\) holds for each \(i\in \{1,\ldots ,n\}\), and that \(\varphi _1,\ldots ,\varphi _n,\varphi \) do not contain any fixpoint operators.
The HES \(\varPhi = (\mathcal {E}, \varphi )\) represents the HFL\(_{\mathbf {Z}}\) formula \( toHFL (\mathcal {E},\varphi )\) defined inductively by: \( toHFL (\epsilon , \varphi ) = \varphi \) and \( toHFL (\mathcal {E};X^\tau =_\alpha \varphi ', \varphi ) = toHFL ([\alpha X^\tau .\varphi '/X]\mathcal {E}, [\alpha X^\tau .\varphi '/X]\varphi )\). Conversely, every HFL\(_{\mathbf {Z}}\) formula can be easily converted to an equivalent HES. In the rest of the paper, we often represent an HFL\(_{\mathbf {Z}}\) formula in the form of HES, and just call it an HFL\(_{\mathbf {Z}}\) formula. We write \(\llbracket \varPhi \rrbracket \) for \(\llbracket toHFL (\varPhi ) \rrbracket \). An HES \( (X_1^{\tau _1} =_{\alpha _1} \varphi _1; \cdots ; X_n^{\tau _n} =_{\alpha _n} \varphi _n, \varphi )\) can be normalized to \( (X_0^{\tau _0} =_{\nu } \varphi ;X_1^{\tau _1} =_{\alpha _1} \varphi _1; \cdots ; X_n^{\tau _n} =_{\alpha _n} \varphi _n, X_0)\) where \(\tau _0\) is the type of \(\varphi \). Thus, we sometimes call just a sequence of equations \(X_0^{\tau _0} =_{\nu } \varphi ;X_1^{\tau _1} =_{\alpha _1} \varphi _1; \cdots ; X_n^{\tau _n} =_{\alpha _n} \varphi _n\) an HES, with the understanding that “the main formula” is the first variable \(X_0\). Also, we often write \(X^\tau \;x_1\,\cdots \, x_k =_\alpha \varphi \) for the equation \(X^\tau =_\alpha \lambda x_1.\cdots \lambda x_k.\varphi \). We often omit type annotations and just write \(X =_\alpha \varphi \) for \(X^\tau =_\alpha \varphi \).
Example 3
3 Warming Up
To help readers get more familiar with HFL\(_{\mathbf {Z}}\) and the idea of reductions, we give here some variations of the examples of verification of fileaccessing programs in Sect. 1, which are instances of the “resource usage verification problem” [15]. General reductions will be discussed in Sects. 5, 6 and 7, after the target language is set up in Sect. 4.
Here, * represents a nondeterministic boolean value. The function \(\texttt {readex}\) reads the file pointer \(x\), and then nondeterministically raises an endoffile (Eof) exception. The main expression (on the third line) first opens file “foo”, calls f to read the file repeatedly, and closes the file upon an endoffile exception. Suppose, as in the example of Sect. 1, we wish to verify that the file “foo” is accessed following the protocol in Fig. 1.
Here, we have added to each function two parameters h and k, which represent an exception handler and a (normal) continuation respectively.
Here, \(\mathtt {n}\) is an integer constant. The function \(\mathtt {f}\) reads \(\mathtt {x}\) \(\mathtt {y}\) times, and then calls the continuation \(\mathtt {k}\). Let \(\mathtt {L}'_{ file }\) be the LTS obtained by adding to \(\mathtt {L}_{ file }\) a new state \(q_2\) and the transition \(q_1{\mathop {\mathbin {\longrightarrow }}\limits ^{\mathtt {end}}}q_2\) (which intuitively means that a program is allowed to terminate in the state \(q_1\)), and let \(\varPhi '\) be \((\mathcal {E}',F\;n\; \mathbf {true}\; (\lambda r.\langle {\mathtt {end}}\rangle \mathbf {true}))\) where \(\mathcal {E}'\) is:
4 Target Language
This section sets up, as the target of program verification, a callbyname^{5} higherorder functional language extended with events. The language is essentially the same as the one used by Watanabe et al. [43] for discussing fair nontermination.
4.1 Syntax and Typing
We assume a finite set \(\mathbf {Ev}\) of names called events, ranged over by \(a\), and a denumerable set of variables, ranged over by \(x,y,\ldots \). Events are used to express temporal properties of programs. We write \(\widetilde{x}\) (\(\widetilde{t}\), resp.) for a sequence of variables (terms, resp.), and write \(\widetilde{x}\) for the length of the sequence.
Any program \((D,t)\) can be normalized to \((D\cup \{\mathbf {main}=t\},\mathbf {main})\) where \(\mathbf {main}\) is a name for the “main” function. We sometimes write just \(D\) for a program \((D,\mathbf {main})\), with the understanding that \(D\) contains a definition of \(\mathbf {main}\).
4.2 Operational Semantics
Example 4
5 May/MustReachability Verification

Mayreachability: “Given a program \(P\) and an event \(a\), may \(P\) raise \(a\)?”

Mustreachability: “Given a program \(P\) and an event \(a\), must \(P\) raise \(a\)?”
Since we are interested in a particular event \(a\), we restrict here the event set \(\mathbf {Ev}\) to a singleton set of the form \(\{a\}\). Then, the mayreachability is formalized as \(a\,{\mathop {\in }\limits ^{?}}\,\mathbf {Traces}(P)\), whereas the mustreachability is formalized as “does every trace in \(\mathbf {FullTraces}(P)\) contain \(a\)?” We encode both problems into the validity of HFL\(_{\mathbf {Z}}\) formulas (without any modal operators \(\langle {a}\rangle \) or \([a]\)), or the HFL\(_{\mathbf {Z}}\) model checking of those formulas against a trivial model (which consists of a single state without any transitions). Since our reductions are sound and complete, the characterizations of their negations –nonreachability and maynonreachability– can also be obtained immediately. Although these are the simplest classes of properties among those discussed in Sects. 5, 6 and 7, they are already large enough to accommodate many program properties discussed in the literature, including lack of assertion failures/uncaught exceptions [22] (which can be characterized as nonreachability; recall the encoding of assertions in Sect. 4), termination [27, 29] (characterized as mustreachability), and nontermination [26] (characterized as maynonreachability).
5.1 MayReachability
As in the examples in Sect. 3, we translate a program to a formula that says “the program may raise an event \(a\)” in a compositional manner. For example, \(\mathbf {event}\ a; t\) can be translated to \(\mathbf {true}\) (since the event will surely be raised immediately), and \(t_1\Box t_2\) can be translated to \(t_1^\dagger \vee t_2^\dagger \) where \(t_i^\dagger \) is the result of the translation of \(t_i\) (since only one of \(t_1\) and \(t_2\) needs to raise an event).
Definition 3
Note that, in the definition of \({D}^{\dagger _{\textit{may}}}\), the order of function definitions in \(D\) does not matter (i.e., the resulting HES is unique up to the semantic equality), since all the fixpoint variables are bound by \(\mu \).
Example 5
Example 6
The following theorem states that \(\varPhi _{P,\textit{may}}\) is a complete characterization of the mayreachability of \(P\).
Theorem 1
Let \(P\) be a program. Then, \(a\in \mathbf {Traces}(P)\) if and only if \(\mathtt {L}_0 \models \varPhi _{P,\textit{may}}\) for \(\mathtt {L}_0 = (\{\mathtt {s}_\star \},\emptyset ,\emptyset ,\mathtt {s}_\star )\).
5.2 MustReachability
The characterization of mustreachability can be obtained by an easy modification of the characterization of mayreachability: we just need to replace branches with logical conjunction.
Definition 4
Example 7
We write \(\mathbf{Must }_a(P)\) if every \(\pi \in \mathbf {FullTraces}(P)\) contains \(a\). The following theorem, which can be proved in a manner similar to Theorem 1, guarantees that \(\varPhi _{P,\textit{must}}\) is indeed a sound and complete characterization of the mustreachability.
Theorem 2
Let \(P\) be a program. Then, \(\mathbf{Must }_a(P)\) if and only if \(\mathtt {L}_0 \models \varPhi _{P,\textit{must}}\) for \(\mathtt {L}_0 = (\{\mathtt {s}_\star \},\emptyset ,\emptyset ,\mathtt {s}_\star )\).
6 Trace Properties
Here we consider the verification problem: “Given a (non\(\omega \)) regular language \(L\) and a program \(P\), does every finite event sequence of \(P\) belong to \(L\)? (i.e. \(\mathbf {FinTraces}(P){\mathop {\subseteq }\limits ^{?}} L\))” and reduce it to an HFL\(_{\mathbf {Z}}\) model checking problem. The verification of fileaccessing programs considered in Sect. 3 may be considered an instance of the problem.
Here we assume that the language \(L\) is closed under the prefix operation; this does not lose generality because \(\mathbf {FinTraces}(P)\) is also closed under the prefix operation. We write \(A_L= (Q,\varSigma ,\delta ,q_0,F)\) for the minimal, deterministic automaton with no dead states (hence the transition function \(\delta \) may be partial). Since \(L\) is prefixclosed and the automaton is minimal, \(w\in L\) if and only if \(\hat{\delta }(q_0,w)\) is defined (where \(\hat{\delta }\) is defined by: \(\hat{\delta }(q,\epsilon )=q\) and \(\hat{\delta }(q,aw) = \hat{\delta }(\delta (q,a),w)\)). We use the corresponding LTS \(\mathtt {L}_L = (Q, \varSigma , \{(q,a,q') \mid \delta (q,a)=q'\}, q_0)\) as the model of the reduced HFL\(_{\mathbf {Z}}\) model checking problem.
Given the LTS \(\mathtt {L}_L\) above, whether an event sequence \(a_1\cdots a_k\) belongs to \(L\) can be expressed as \(\mathtt {L}_L {\mathop {\models }\limits ^{?}} \langle {a_1}\rangle \cdots \langle {a_k}\rangle \mathbf {true}\). Whether all the event sequences in \(\{a_{j,1}\cdots a_{j,k_j}\mid j\in \{1,\ldots ,n\}\}\) belong to \(L\) can be expressed as \(\mathtt {L}_L {\mathop {\models }\limits ^{?}} \bigwedge _{j\in \{1,\ldots ,n\}} \langle {a_{j,1}}\rangle \cdots \langle {a_{j,k_j}}\rangle \mathbf {true}\). We can lift these translations for event sequences to the translation from a program (which can be considered a description of a set of event sequences) to an HFL\(_{\mathbf {Z}}\) formula, as follows.
Definition 5
Example 8
Theorem 3
Let \(P\) be a program and \(L\) be a regular, prefixclosed language. Then, \(\mathbf {FinTraces}(P)\subseteq L\) if and only if \(\mathtt {L}_L\models \varPhi _{P,\textit{path}}\).
As in Sect. 5, we first prove the theorem for programs in normal form, and then lift it to recursionfree programs by using the preservation of the semantics of HFL\(_{\mathbf {Z}}\) formulas by reductions, and further to arbitrary programs by using the (co)continuity of the functions represented by fixpointfree HFL\(_{\mathbf {Z}}\) formulas. See [23] for a concrete proof.
7 LinearTime Temporal Properties
This section considers the following problem: “Given a program \(P\) and an \(\omega \)regular word language \(L\), does \(\mathbf {InfTraces}(P){\cap } L = \emptyset \) hold\(?\)”. From the viewpoint of program verification, \(L\) represents the set of “bad” behaviors. This can be considered an extension of the problems considered in the previous sections.
The general translation is more involved due to the presence of higherorder functions, but, as in the example above, the overall translation consists of two steps. We first replicate functions according to what events may occur between two recursive calls, and reduce the problem \(\mathbf {InfTraces}(P)\cap L{\mathop {=}\limits ^{?}} \emptyset \) to a problem of analyzing which functions are recursively called infinitely often, which we call a callsequence analysis. We can then reduce the callsequence analysis to HFL model checking in a rather straightforward manner (though the proof of the correctness is nontrivial). The resulting HFL formula actually does not contain modal operators.^{7} So, as in Sect. 5, the resulting problem is the validity checking of HFL formulas without modal operators.
In the rest of this section, we first introduce the callsequence analysis problem and its reduction to HFL model checking in Sect. 7.1. We then show how to reduce the temporal verification problem \(\mathbf {InfTraces}(P)\cap L{\mathop {=}\limits ^{?}} \emptyset \) to an instance of the callsequence analysis problem in Sect. 7.2.
7.1 CallSequence Analysis
We define the notion of “recursive calls” and callsequences formally below.
Definition 6
For example, for \(P_{ app }\) above, \(\mathbf {Callseq}(P)\) is the prefix closure of \(\{(f_bf_a^5)^\omega \}\cup \{s\cdot \mathtt {app}\mid \text{ s } \text{ is } \text{ a } \text{ nonempty } \text{ finite } \text{ prefix } \text{ of } (f_bf_a^5)^\omega \}\), and \(\mathbf {InfCallseq}(P)\) is the singleton set \(\{(f_bf_a^5)^\omega \}\).
Definition 7
(Callsequence analysis). A priority assignment for a program \( P \) is a function \( \varOmega \mathbin {:}\mathbf {funs}(P) \rightarrow \mathbb {N} \) from the set of function symbols of \( P \) to the set \(\mathbb {N}\) of natural numbers. We write \(\models _{ csa } (P,\varOmega )\) if every infinite callsequence \(g_0g_1g_2\dots \in \mathbf {InfCallseq}(P)\) satisfies the parity condition w.r.t. \( \varOmega \), i.e., the largest number occurring infinitely often in \( \varOmega (g_0) \varOmega (g_1) \varOmega (g_2) \dots \) is even. Callsequence analysis is the problem of, given a program \( P \) with a priority assignment \( \varOmega \), deciding whether \(\models _{ csa } (P,\varOmega )\) holds.
For example, for \(P_{ app }\) and the priority assignment \(\varOmega _{ app } = \{\mathtt {app}\mapsto 3, f_a\mapsto 1, f_b\mapsto 2\}\), \(\models _ csa (P_{ app }, \varOmega _{ app })\) holds.
The callsequence analysis can naturally be reduced to HFL model checking against the trivial LTS \( \mathtt {L}_0 = (\{\mathtt {s}_\star \}, \emptyset , \emptyset , \mathtt {s}_\star ) \) (or validity checking).
Definition 8
The following theorem states the soundness and completeness of the reduction. See [23] for a proof.
Theorem 4
Let \( P \) be a program and \( \varOmega \) be a priority assignment for \(P\). Then \(\models _ csa (P,\varOmega )\) if and only if \( \mathtt {L}_0 \models \varPhi _{(P,\varOmega ), csa }\).
Example 9
7.2 From Temporal Verification to CallSequence Analysis
This subsection shows a reduction from the temporal verification problem \(\mathbf {InfTraces}(P) \cap L {\mathop {=}\limits ^{?}} \emptyset \) to a callsequence analysis problem \({\mathop {\models }\limits ^{?}}_{ csa }(P',\varOmega )\).
For the sake of simplicity, we assume without loss of generality that every program \(P=(D, t)\) in this section is nonterminating and every infinite reduction sequence produces infinite events, so that \(\mathbf {FullTraces}(P) = \mathbf {InfTraces}(P)\) holds. We also assume that the \(\omega \)regular language \(L\) for the temporal verification problem is specified by using a nondeterministic, parity word automaton [10]. We recall the definition of nondeterministic, parity word automata below.
Definition 9
(Parity automaton). A nondeterministic parity word automaton is a quintuple \(\mathcal {A}= (Q, \varSigma , \delta , q_I, \varOmega )\) where (i) \(Q\) is a finite set of states; (ii) \(\varSigma \) is a finite alphabet; (iii) \(\delta \), called a transition function, is a total map from \(Q\times \varSigma \) to \(2^Q\); (iv) \(q_I\in Q\) is the initial state; and (v) \(\varOmega \in Q \rightarrow \mathbb {N}\) is the priority function. A run of \(\mathcal {A}\) on an \(\omega \)word \(a_0 a_1 \dots \in \varSigma ^{\omega }\) is an infinite sequence of states \(\rho = \rho (0) \rho (1) \dots \in Q^{\omega }\) such that (i) \(\rho (0) = q_I\), and (ii) \(\rho (i+1) \in \delta (\rho (i),a_i)\) for each \(i\in \omega \). An \(\omega \)word \(w \in \varSigma ^{\omega }\) is accepted by \(\mathcal {A}\) if, there exists a run \(\rho \) of \(\mathcal {A}\) on \(w\) such that \( \mathbf {max}\{\varOmega (q) \mid q \in \mathbf {Inf}(\rho )\} \text { is even} \), where \(\mathbf {Inf}(\rho )\) is the set of states that occur infinitely often in \(\rho \). We write \( \mathcal {L}(\mathcal {A}) \) for the set of \( \omega \)words accepted by \( \mathcal {A}\).
For technical convenience, we assume below that \(\delta (q,a)\ne \emptyset \) for every \(q\in Q\) and \(a\in \varSigma \); this does not lose generality since if \(\delta (q,a)=\emptyset \), we can introduce a new “dead” state \(q_{ dead }\) (with priority 1) and change \(\delta (q,a)\) to \(\{q_{ dead }\}\). Given a parity automaton \(\mathcal {A}\), we refer to each component of \(\mathcal {A}\) by \(Q_{\mathcal {A}}\), \(\varSigma _{\mathcal {A}}\), \(\delta _{\mathcal {A}}\), \(q_{I,{\mathcal {A}}}\) and \(\varOmega _{\mathcal {A}}\).
Example 10
Consider the automaton \(\mathcal {A}_{ab}=(\{q_a,q_b\}, \{\mathtt {a},\mathtt {b}\}, \delta , q_a, \varOmega )\), where \(\delta \) is as given in Fig. 4, \(\varOmega (q_a)=0\), and \(\varOmega (q_b)=1\). Then, \(\mathcal {L}(\mathcal {A}_{ab})= \overline{(\mathtt {a}^*\mathtt {b})^\omega } = (\mathtt {a}^*\mathtt {b})^*\mathtt {a}^\omega \).
The goal of this subsection is, given a program \(P\) and a parity word automaton \(\mathcal {A}\), to construct another program \(P'\) and a priority assignment \(\varOmega \) for \(P'\), such that \(\mathbf {InfTraces}(P)\cap \mathcal {L}(\mathcal {A})=\emptyset \) if and only if \(\models _{ csa }(P',\varOmega )\).
Definition 10
We often write \((\theta _1,m_1)\wedge \cdots \wedge (\theta _k,m_k)\) for \(\bigwedge _{1 \le i \le k} (\theta _i, m_i)\), and \(\top \) when \(k=0\). Intuitively, the type \(q\) describes expressions of simple type \(\star \), which may be evaluated when the automaton \(\mathcal {A}\) is in the state \(q\) (here, we have in mind an execution of the product of a program and the automaton, where the latter takes events produced by the program and changes its states). The type \((\bigwedge _{1 \le i \le k} (\theta _i, m_i))\rightarrow \theta \) describes functions that take an argument, use it according to types \(\theta _1,\ldots ,\theta _k\), and return a value of type \(\theta \). Furthermore, the part \(m_i\) describes that the argument may be used as a value of type \(\theta _i\) only when the largest priority visited since the function is called is \(m_i\). For example, given the automaton in Example 10, the function \(\lambda x.(\mathbf {event}\ \mathtt {a}; x)\) may have types \((q_a,0)\rightarrow q_a\) and \((q_a,0)\rightarrow q_b\), because the body may be executed from state \(q_a\) or \(q_b\) (thus, the return type may be any of them), but \(x\) is used only when the automaton is in state \(q_a\) and the largest priority visited is \(1\). In contrast, \(\lambda x.(\mathbf {event}\ \mathtt {b}; x)\) have types \((q_b,1)\rightarrow q_a\) and \((q_b,1)\rightarrow q_b\).
Using the intersection types above, we shall define a typebased transformation relation of the form \(\varGamma \vdash _{\mathcal {A}}t:\theta \Rightarrow t'\), where \(t\) and \(t'\) are the source and target terms of the transformation, and \(\varGamma \), called an intersection type environment, is a finite set of type bindings of the form \(x \mathbin {:}\mathtt {int}\) or \(x \mathbin {:}(\theta , m, m')\). We allow multiple type bindings for a variable \( x \) except for \( x \mathbin {:}\mathtt {int}\) (i.e. if \( x \mathbin {:}\mathtt {int}\in \varGamma \), then this must be the unique type binding for \(x \) in \( \varGamma \)). The binding \(x \mathbin {:}(\theta , m, m')\) means that \(x\) should be used as a value of type \(\theta \) when the largest priority visited is \(m\); \(m'\) is auxiliary information used to record the largest priority encountered so far.
We now define the transformation for programs. A toplevel type environment \( \varXi \) is a finite set of type bindings of the form \( x : (\theta , m) \). Like intersection type environments, \( \varXi \) may have more than one binding for each variable. We write \( \varXi \vdash _{\mathcal {A}}t : \theta \) to mean \( \{ x : (\theta , m, 0) \mid x : (\theta , m) \in \varXi \} \vdash _{\mathcal {A}}t : \theta \). For a set \( D \) of function definitions, we write \( \varXi \vdash _{\mathcal {A}}D \Rightarrow D' \) if \( dom (D') = \{\, f_{\theta ,m} \mid f : (\theta , m) \in \varXi \,\} \) and \( \varXi \vdash _{\mathcal {A}}D(f) : \theta \Rightarrow D'(f_{\theta ,m}) \) for every \( f \mathbin {:}(\theta , m) \in \varXi \). For a program \( P = (D, t) \), we write \( \varXi \vdash _{\mathcal {A}}P \Rightarrow (P',\varOmega ') \) if \( P' = (D', t') \), \( \varXi \vdash _{\mathcal {A}}D \Rightarrow D' \) and \( \varXi \vdash _{\mathcal {A}}t : q_I\Rightarrow t' \), with \(\varOmega '(f_{\theta ,m})=m+1\) for each \(f_{\theta ,m}\in dom (D')\). We just write \(\vdash _{\mathcal {A}}P\Rightarrow (P',\varOmega ')\) if \( \varXi \vdash _{\mathcal {A}}P \Rightarrow (P',\varOmega ') \) holds for some \(\varXi \).
Example 11
The following theorems below claim that our reduction is sound and complete, and that there is an effective algorithm for the reduction: see [23] for proofs.
Theorem 5
Let \( P\) be a program and \( \mathcal {A}\) be a parity automaton. Suppose that \( \varXi \vdash _{\mathcal {A}}P \Rightarrow (P',\varOmega ) \). Then \( \mathbf {InfTraces}(P) \cap \mathcal {L}(\mathcal {A}) = \emptyset \) if and only if \(\models _ csa (P',\varOmega )\).
Theorem 6
For every \( P \) and \( \mathcal {A}\), one can effectively construct \( \varXi \), \( P' \) and \(\varOmega \) such that \( \varXi \vdash _{\mathcal {A}}P \Rightarrow (P',\varOmega ) \).
The proof of Theorem 6 above also implies that the reduction from temporal property verification to callsequence analysis can be performed in polynomial time. Combined with the reduction from callsequence analysis to HFL model checking, we have thus obtained a polynomialtime reduction from the temporal verification problem \(\mathbf {InfTraces}(P){\mathop {\subseteq }\limits ^{?}} \mathcal {L}(\mathcal {A})\) to HFL model checking.
8 Related Work
As mentioned in Sect. 1, our reduction from program verification problems to HFL model checking problems has been partially inspired by the translation of Kobayashi et al. [19] from HORS model checking to HFL model checking. As in their translation (and unlike in previous applications of HFL model checking [28, 42]), our translation switches the roles of properties and models (or programs) to be verified. Although a combination of their translation with Kobayashi’s reduction from program verification to HORS model checking [17, 18] yields an (indirect) translation from finitedata programs to pure HFL model checking problems, the combination does not work for infinitedata programs. In contrast, our translation is sound and complete even for infinitedata programs. Among the translations in Sects. 5, 6 and 7, the translation in Sect. 7.2 shares some similarity to their translation, in that functions and their arguments are replicated for each priority. The actual translations are however quite different; ours is typedirected and optimized for a given automaton, whereas their translation is not. This difference comes from the difference of the goals: the goal of [16] was to clarify the relationship between HORS and HFL, hence their translation was designed to be independent of an automaton. The proof of the correctness of our translation in Sect. 7 is much more involved due to the need for dealing with integers. Whilst the proof of [19] could reuse the typebased characterization of HORS model checking [21], we had to generalize arguments in both [19, 21] to work on infinitedata programs.
Lange et al. [16] have shown that various process equivalence checking problems (such as bisimulation and trace equivalence) can be reduced to (pure) HFL model checking problems. The idea of their reduction is quite different from ours. They reduce processes to LTSs, whereas we reduce programs to HFL formulas.
Major approaches to automated or semiautomated higherorder program verification have been HORS model checking [17, 18, 22, 27, 31, 33, 43], (refinement) type systems [14, 24, 34, 35, 36, 39, 41, 44], Horn clause solving [2, 7], and their combinations. As already discussed in Sect. 1, compared with the HORS model checking approach, our new approach provides more uniform, streamlined methods. Whilst the HORS model checking approach is for fully automated verification, our approach enables various degrees of automation: after verification problems are automatically translated to HFL\(_{\mathbf {Z}}\) formulas, one can prove them (i) interactively using a proof assistant like Coq (see [23]), (ii) semiautomatically, by letting users provide hints for induction/coinduction and discharging the rest of proof obligations by (some extension of) an SMT solver, or (iii) fully automatically by recasting the techniques used in the HORSbased approach; for example, to deal with the \(\nu \)only fragment of HFL\(_{\mathbf {Z}}\), we can reuse the technique of predicate abstraction [22]. For a more technical comparison between the HORSbased approach and our HFLbased approach, see [23].
As for typebased approaches [14, 24, 34, 35, 36, 39, 41, 44], most of the refinement type systems are (i) restricted to safety properties, and/or (ii) incomplete. A notable exception is the recent work of Unno et al. [40], which provides a relatively complete type system for the classes of properties discussed in Sect. 5. Our approach deals with a wider class of properties (cf. Sects. 6 and 7). Their “relative completeness” property relies on Godel coding of functions, which cannot be exploited in practice.
The reductions from program verification to Horn clause solving have recently been advocated [2, 3, 4] or used [34, 39] (via refinement type inference problems) by a number of researchers. Since Horn clauses can be expressed in a fragment of HFL without modal operators, fixpoint alternations (between \(\nu \) and \(\mu \)), and higherorder predicates, our reductions to HFL model checking may be viewed as extensions of those approaches. Higherorder predicates and fixpoints over them allowed us to provide sound and complete characterizations of properties of higherorder programs for a wider class of properties. Bjørner et al. [16] proposed an alternative approach to obtaining a complete characterization of safety properties, which defunctionalizes higherorder programs by using algebraic data types and then reduces the problems to (firstorder) Horn clauses. A disadvantage of that approach is that control flow information of higherorder programs is also encoded into algebraic data types; hence even for finitedata higherorder programs, the Horn clauses obtained by the reduction belong to an undecidable fragment. In contrast, our reductions yield pure HFL model checking problems for finitedata programs. Burn et al. [16] have recently advocated the use of higherorder (constrained) Horn clauses for verification of safety properties (i.e., which correspond to the negation of mayreachability properties discussed in Sect. 5.1 of the present paper) of higherorder programs. They interpret recursion using the least fixpoint semantics, so their higherorder Horn clauses roughly corresponds to a fragment of the HFL\(_{\mathbf {Z}}\) without modal operators and fixpoint alternations. They have not shown a general, concrete reduction from safety property verification to higherorder Horn clause solving.
The characterization of the reachability problems in Sect. 5 in terms of formulas without modal operators is a reminiscent of predicate transformers [9, 13] used for computing the weakest preconditions of imperative programs. In particular, [16] and [16] respectively used least fixpoints to express weakest preconditions for whileloops and recursions.
9 Conclusion
We have shown that various verification problems for higherorder functional programs can be naturally reduced to (extended) HFL model checking problems. In all the reductions, a program is mapped to an HFL formula expressing the property that the behavior of the program is correct. For developing verification tools for higherorder functional programs, our reductions allow us to focus on the development of (automated or semiautomated) HFL\(_{\mathbf {Z}}\) model checking tools (or, even more simply, theorem provers for HFL\(_{\mathbf {Z}}\) without modal operators, as the reductions of Sects. 5 and 7 yield HFL formulas without modal operators). To this end, we have developed a prototype model checker for pure HFL (without integers), which will be reported in a separate paper. Work is under way to develop HFL\(_{\mathbf {Z}}\) model checkers by recasting the techniques [22, 26, 27, 43] developed for the HORSbased approach, which, together with the reductions presented in this paper, would yield fully automated verification tools. We have also started building a Coq library for interactively proving HFL\(_{\mathbf {Z}}\) formulas, as briefly discussed in [23]. As a final remark, although one may fear that our reductions may map program verification problems to “harder” problems due to the expressive power of HFL\(_{\mathbf {Z}}\), it is actually not the case at least for the classes of problems in Sects. 5 and 6, which use the only alternationfree fragment of HFL\(_{\mathbf {Z}}\). The model checking problems for \(\mu \)only or \(\nu \)only HFL\(_{\mathbf {Z}}\) are semidecidable and cosemidecidable respectively, like the source verification problems of may/mustreachability and their negations of closed programs.
Footnotes
 1.
In this section, we use only a fragment of HFL that can be expressed in the modal \(\mu \)calculus. Some familiarity with the modal \(\mu \)calculus [25] would help.
 2.
Here, for the sake of simplicity, we assume that we are interested in the usage of the single file pointer \(x\), so that the name \(x\) can be ignored in HFL formulas; usage of multiple files can be tracked by using the technique of [16].
 3.
This does not mean that invariant discovery is unnecessary; invariant discovery is just postponed to the later phase of discharging verification conditions, so that it can be uniformly performed among various verification problems.
 4.
Note that the derivation of each judgment \(\varDelta \vdash _{\mathtt {H}}\varphi :\sigma \) is unique if there is any.
 5.
Callbyvalue programs can be handled by applying the CPS transformation before applying the reductions to HFL model checking.
 6.
Unlike in Sect. 3, the variables are bound by \(\nu \) since we are not concerned with the termination property here.
 7.
In the example above, we can actually remove \(\langle {\mathtt {a}}\rangle \) and \(\langle {\mathtt {b}}\rangle \), as information about events has been taken into account when \(f\) was duplicated.
Notes
Acknowledgment
We would like to thank anonymous referees for useful comments. This work was supported by JSPS KAKENHI Grant Number JP15H05706 and JP16K16004.
References
 1.Axelsson, R., Lange, M., Somla, R.: The complexity of model checking higherorder fixpoint logic. Logical Methods Comput. Sci. 3(2), 1–33 (2007)MathSciNetCrossRefGoogle Scholar
 2.Bjørner, N., Gurfinkel, A., McMillan, K., Rybalchenko, A.: Horn clause solvers for program verification. In: Beklemishev, L.D., Blass, A., Dershowitz, N., Finkbeiner, B., Schulte, W. (eds.) Fields of Logic and Computation II. LNCS, vol. 9300, pp. 24–51. Springer, Cham (2015). https://doi.org/10.1007/9783319235349_2CrossRefGoogle Scholar
 3.Bjørner, N., McMillan, K.L., Rybalchenko, A.: Program verification as satisfiability modulo theories. In: SMT 2012, EPiC Series in Computing, vol. 20, pp. 3–11. EasyChair (2012)Google Scholar
 4.Bjørner, N., McMillan, K.L., Rybalchenko, A.: Higherorder program verification as satisfiability modulo theories with algebraic datatypes. CoRR, abs/1306.5264 (2013)Google Scholar
 5.Blass, A., Gurevich, Y.: Existential fixedpoint logic. In: Börger, E. (ed.) Computation Theory and Logic. LNCS, vol. 270, pp. 20–36. Springer, Heidelberg (1987). https://doi.org/10.1007/3540181709_151CrossRefGoogle Scholar
 6.Blume, M., Acar, U.A., Chae, W.: Exception handlers as extensible cases. In: Ramalingam, G. (ed.) APLAS 2008. LNCS, vol. 5356, pp. 273–289. Springer, Heidelberg (2008). https://doi.org/10.1007/9783540893301_20CrossRefGoogle Scholar
 7.Burn, T.C., Ong, C.L., Ramsay, S.J.: Higherorder constrained horn clauses for verification. PACMPL 2(POPL), 11:1–11:28 (2018)Google Scholar
 8.Carayol, A., Serre, O.: Collapsible pushdown automata and labeled recursion schemes: equivalence, safety and effective selection. In: LICS 2012, pp. 165–174. IEEE (2012)Google Scholar
 9.Dijkstra, E.W.: Guarded commands, nondeterminacy and formal derivation of programs. Commun. ACM 18(8), 453–457 (1975)MathSciNetCrossRefGoogle Scholar
 10.Grädel, E., Thomas, W., Wilke, T. (eds.): Automata Logics, and Infinite Games: A Guide to Current Research. LNCS, vol. 2500. Springer, Heidelberg (2002). https://doi.org/10.1007/3540363874CrossRefMATHGoogle Scholar
 11.Grellois, C., Melliès, P.: Relational semantics of linear logic and higherorder model checking. In: Proceedings of CSL 2015, LIPIcs, vol. 41, pp. 260–276 (2015)Google Scholar
 12.Haddad, A.: Model checking and functional program transformations. In: Proceedings of FSTTCS 2013, LIPIcs, vol. 24, pp. 115–126 (2013)Google Scholar
 13.Hesselink, W.H.: Predicatetransformer semantics of general recursion. Acta Inf. 26(4), 309–332 (1989)MathSciNetMATHGoogle Scholar
 14.Hofmann, M., Chen, W.: Abstract interpretation from Büchi automata. In: Proceedings of CSLLICS 2014, pp. 51:1–51:10. ACM (2014)Google Scholar
 15.Igarashi, A., Kobayashi, N.: Resource usage analysis. ACM Trans. Prog. Lang. Syst. 27(2), 264–313 (2005)CrossRefGoogle Scholar
 16.Knapik, T., Niwiński, D., Urzyczyn, P.: Higherorder pushdown trees are easy. In: Nielsen, M., Engberg, U. (eds.) FoSSaCS 2002. LNCS, vol. 2303, pp. 205–222. Springer, Heidelberg (2002). https://doi.org/10.1007/3540459316_15CrossRefGoogle Scholar
 17.Kobayashi, N.: Types and higherorder recursion schemes for verification of higherorder programs. In: Proceedings of POPL, pp. 416–428. ACM Press (2009)CrossRefGoogle Scholar
 18.Kobayashi, N.: Model checking higherorder programs. J. ACM 60(3), 1–62 (2013)MathSciNetCrossRefGoogle Scholar
 19.Kobayashi, N., Lozes, É., Bruse, F.: On the relationship between higherorder recursion schemes and higherorder fixpoint logic. In: Proceedings of POPL 2017, pp. 246–259 (2017)Google Scholar
 20.Kobayashi, N., Matsuda, K., Shinohara, A., Yaguchi, K.: Functional programs as compressed data. High.Order Symbolic Comput. 25(1), 39–84 (2013)MathSciNetCrossRefGoogle Scholar
 21.Kobayashi, N., Ong, C.H.L.: A type system equivalent to the modal mucalculus model checking of higherorder recursion schemes. In: Proceedings of LICS 2009, pp. 179–188 (2009)Google Scholar
 22.Kobayashi, N., Sato, R., Unno, H.: Predicate abstraction and CEGAR for higherorder model checking. In: Proceedings of PLDI, pp. 222–233. ACM Press (2011)CrossRefGoogle Scholar
 23.Kobayashi, N., Tsukada, T., Watanabe, K.: Higherorder program verification via HFL model checking. CoRR abs/1710.08614 (2017). http://arxiv.org/abs/1710.08614
 24.Koskinen, E., Terauchi, T.: Local temporal reasoning. In: Proceedings of CSLLICS 2014, pp. 59:1–59:10. ACM (2014)Google Scholar
 25.Kozen, D.: Results on the propositional \(\mu \)calculus. Theor. Comput. Sci. 27, 333–354 (1983)MathSciNetCrossRefGoogle Scholar
 26.Kuwahara, T., Sato, R., Unno, H., Kobayashi, N.: Predicate abstraction and CEGAR for disproving termination of higherorder functional programs. In: Kroening, D., Păsăreanu, C.S. (eds.) CAV 2015. LNCS, vol. 9207, pp. 287–303. Springer, Cham (2015). https://doi.org/10.1007/9783319216683_17CrossRefGoogle Scholar
 27.Kuwahara, T., Terauchi, T., Unno, H., Kobayashi, N.: Automatic termination verification for higherorder functional programs. In: Shao, Z. (ed.) ESOP 2014. LNCS, vol. 8410, pp. 392–411. Springer, Heidelberg (2014). https://doi.org/10.1007/9783642548338_21CrossRefGoogle Scholar
 28.Lange, M., Lozes, É., Guzmán, M.V.: Modelchecking process equivalences. Theor. Comput. Sci. 560, 326–347 (2014)MathSciNetCrossRefGoogle Scholar
 29.LedesmaGarza, R., Rybalchenko, A.: Binary reachability analysis of higher order functional programs. In: Miné, A., Schmidt, D. (eds.) SAS 2012. LNCS, vol. 7460, pp. 388–404. Springer, Heidelberg (2012). https://doi.org/10.1007/9783642331251_26CrossRefGoogle Scholar
 30.Lozes, É.: A typedirected negation elimination. In: Proceedings FICS 2015, EPTCS, vol. 191, pp. 132–142 (2015)Google Scholar
 31.Murase, A., Terauchi, T., Kobayashi, N., Sato, R., Unno, H.: Temporal verification of higherorder functional programs. In: Proceedings of POPL 2016, pp. 57–68 (2016)CrossRefGoogle Scholar
 32.Ong, C.H.L.: On modelchecking trees generated by higherorder recursion schemes. In: LICS 2006, pp. 81–90. IEEE Computer Society Press (2006)Google Scholar
 33.Ong, C.H.L., Ramsay, S.: Verifying higherorder programs with patternmatching algebraic data types. In: Proceedings of POPL, pp. 587–598. ACM Press (2011)Google Scholar
 34.Rondon, P.M., Kawaguchi, M., Jhala, R.: Liquid types. PLDI 2008, 159–169 (2008)MATHGoogle Scholar
 35.Skalka, C., Smith, S.F., Horn, D.V.: Types and trace effects of higher order programs. J. Funct. Program. 18(2), 179–249 (2008)MathSciNetCrossRefGoogle Scholar
 36.Terauchi, T.: Dependent types from counterexamples. In: Proceedings of POPL, pp. 119–130. ACM (2010)Google Scholar
 37.Tobita, Y., Tsukada, T., Kobayashi, N.: Exact flow analysis by higherorder model checking. In: Schrijvers, T., Thiemann, P. (eds.) FLOPS 2012. LNCS, vol. 7294, pp. 275–289. Springer, Heidelberg (2012). https://doi.org/10.1007/9783642298226_22CrossRefGoogle Scholar
 38.Tsukada, T., Ong, C.L.: Compositional higherorder model checking via \(\omega \)regular games over Böhm trees. In: Proceedings of CSLLICS 2014, pp. 78:1–78:10. ACM (2014)Google Scholar
 39.Unno, H., Kobayashi, N.: Dependent type inference with interpolants. In: PPDP 2009, pp. 277–288. ACM (2009)Google Scholar
 40.Unno, H., Satake, Y., Terauchi, T.: Relatively complete refinement type system for verification of higherorder nondeterministic programs. PACMPL 2(POPL), 12:01–12:29 (2018)Google Scholar
 41.Unno, H., Terauchi, T., Kobayashi, N.: Automating relatively complete verification of higherorder functional programs. In: POPL 2013. pp. 75–86. ACM (2013)Google Scholar
 42.Viswanathan, M., Viswanathan, R.: A higher order modal fixed point logic. In: Gardner, P., Yoshida, N. (eds.) CONCUR 2004. LNCS, vol. 3170, pp. 512–528. Springer, Heidelberg (2004). https://doi.org/10.1007/9783540286448_33CrossRefGoogle Scholar
 43.Watanabe, K., Sato, R., Tsukada, T., Kobayashi, N.: Automatically disproving fair termination of higherorder functional programs. In: Proceedings of ICFP 2016, pp. 243–255. ACM (2016)Google Scholar
 44.Zhu, H., Nori, A.V., Jagannathan, S.: Learning refinement types. In: Proceedings of ICFP 2015, pp. 400–411. ACM (2015)MathSciNetCrossRefGoogle Scholar
Copyright information
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this book are included in the book's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the book's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.