System FR as Foundations for Stainless

Automatically verifying the correctness of higher-order programs is a challenging problem that applies to most modern programming languages and proof assistants. Despite extensive research in program verifiers (Nipkow et al., 2002a; Bertot and Castéran, 2004a; Abel, 2010; Norell, 2007; Brady, 2013; Vazou et al., 2014; Swamy et al., 2013; Leino, 2010) there remain significant challenges and trade-offs in checking safety and termination. A motivation for our work are implementations that verify polymorphic functional programs using SMT solvers (Suter et al., 2011; Vazou et al., 2014). To focus on foundations, we look at simpler verifiers that do not perform invariant inference and are mostly based on unfolding recursive definitions and encoding of higher-order functions into SMT theories (Suter et al., 2011; Voirol et al., 2015). A recent implementation of such a verifier is the Stainless system ¹¹1https://github.com/epfl-lara/stainless, which claims to handle a subset of Scala (Odersky et al., 2008). The goal of Stainless is to verify that function contracts hold and that all functions terminate. Unfortunately, the termination checking procedure is not documented to the best of our knowledge and even its soundness can be doubted. Researchers have shown (Hupel and Kuncak, 2016) how to map certain patterns of specified Scala programs into Isabelle/HOL to ensure verification, but the link-up imposes a number of restrictions on data type definitions and can certify only a fraction of programs that the original verifier can prove. This paper seeks foundations for verification and termination checking of functional programs with such a rich set of features.

Termination is desirable for many executable functions in programs and is even more important in formal specifications. A non-terminating function definition such as $f\left(x\right)=1+f\left(x\right)$ could be easily mapped to a contradiction and violate the conservative extension principle for definitions. Yet termination in the presence of higher-order functions and data types is challenging to ensure. For example, when using non-monotonic recursive types, terms can diverge even without the explicit use of recursive functions, as illustrated by the following snippet of Scala code:

Furthermore, even though the concept of termination for all function inputs is an intuitively clear property, its modular definition is subtle: a higher order function $G$ taking another function $f$ as an argument should terminate when given any terminating function $f$, which in term can be applied to expressions involving further calls to $G$. We were thus led to type theoretic techniques, where reducibility method has long been used to show strong normalization of expressive calculi (Tait, 1967), (Girard, 1990, Chapter 6), (Harper, 2016). As a natural framework for analyzing support for first-class functions with preconditions and post-conditions we embraced the ideas of refinement dependent types similar to those in Liquid Haskell (Vazou et al., 2014) with refinement-based notion of subtyping. To explain verification condition generation in higher-order case (including the question of which assumptions should be visible inside for a given assertion), we resorted to well-known dependent ($\Pi$) function types. To support polymorphism we incorporated type quantifiers, as in System F (Girard, 1971, 1990). We found that the presence of refinement types allowed us to explain soundness of well-founded recursion based on user-defined measures. To provide expressive support for iterative unfolding of recursive functions, we introduced rules to make function bodies available while type checking of recursive functions. For recursive types, many existing systems introduce separate notions of inductive and co-inductive definitions. We found this distinction less natural for developers and chose to support expressive recursive types (without a necessary restriction to positive recursion) using sized types (Abel, 2010). We draw inspiration from a number of existing systems, yet our solution has a new combination of features that work nicely together. For example, we can encode user-defined termination measures for functions using a general fixpoint combinator and refinement types that ensure termination condition semantically. The recursion in programs is thus not syntactically restricted as in, e.g., System F.

We combined these features into a new type system, System FR, which we present as a bidirectional type checking algorithm. The algorithm generates type checking and type inference goals by traversing terms and types, until it reaches a point where it has to check that a given term evaluates to true. This typically arises when we want to check that a term $t$ has a refinement type $\{x:T|b\}$, which is the case when $t$ has type $T$, and when the term $b$ evaluates to true in the context where $x$ equals $t$. Following the tradition of SMT-based verifiers (Detlefs et al., 1998; Barnett et al., 2004), we call checks that some terms evaluate to true verification conditions.

We prove the soundness of our type system using a reducibility interpretation of types. The goal of our verification system is to ensure that a given term belongs to the semantic denotation of a given type. For simple types such as natural numbers, this denotation is the set of untyped lambda calculus terms that evaluate, in a finite number of steps, to a non-negative integer. For function types the denotation are, as is typical in reducibility approaches, terms that, when applied to terms in denotation of argument type, evaluate to terms in the denotation of the result type. Such denotation gives us a unified framework for function contracts expressed as refinement types. The approach ensures termination of programs because the semantics of types only contain terms that are terminating in call-by-value semantics.

We have formally proven using the Coq proof assistant (Bertot and Castéran, 2004a) the soundness of our typing algorithm, implying that when verification conditions generated for checking that a term $t$ belongs to a type $T$ are semantically valid, the term $t$ belongs to the semantic denotation of the type $T$. The bidirectional typing algorithm handles the expressive types in a deterministic and predictable way, which enables good and localized error reporting to the user. To solve generated verification conditions, we use existing implementation invoking the Inox solver²²2https://github.com/epfl-lara/inox that translates them into first-order language of SMT solvers (Voirol et al., 2015). Our semantics of types provides a definition of soundness for such solvers; any solver that respects the semantics can be used with our verification condition generator. Our bidirectional type checking algorithm thus becomes a new, trustworthy verification condition generator for Stainless. We were successful in verifying many existing Stainless benchmarks using the new approach.

We summarize our contributions as follows:

• We present a rich type system, called System FR, that combines System F with dependent types, refinements, equality types, and recursive types (Sections 3 and 4).

• We define a bidirectional type-checking algorithm for System FR (Section 5.6). Our algorithm generates verification conditions that are then solved by the (existing) SMT-based solver Inox.

• We prove

  ⬇ def f(x: ${\tau }_1$): ${\tau }_2$ = {   require($pre$[x])   decreases($m$[x])   $E$[x, f] } ensuring { res $\Rightarrow$ $post$[x, res] }

  2. Examples of Program Verification and Termination Checking

  Our goal is to verify correctness and termination of pure Scala functions written as in Figure 1. $pre$[x] is the precondition of the function f, and is written by the user in the same language as the body of f. The precondition may contain arbitrary expressions and calls to other functions. Similarly, the user specifies in $post$ the property that the results of the function should satisfy. To ensure termination of f (which might call itself recursively), the user may also provide a measure using the decreases keyword, which is also an expression (of type $Nat$, the type of natural numbers) written in the same language. ${\tau }_1$ and ${\tau }_2$ may be arbitrary types, including function types or algebraic data types. Informally, the function is terminating and correct, if, for every value v of type ${\tau }_1$ such that $pre$[v] evaluates to $true$, f(v) returns (in a finite number of steps) a value res of type ${\tau }_2$ such that $post$[v,res] evaluates to $true$. By using dependent and refinement types, this can be summarized by saying that the function f has type: $\Pi x:\{x:{\tau }_1|pre\left[x\right]\}.\{res:{\tau }_2|post[x,res]\}.$

  ⬇ sealed abstract class List case object Nil extends List case class Cons(head: $Z$, tail: List) extends List def filter(l: List, p: $Z$ $\Rightarrow$ Boolean): List = {   decreases(l)   l match {     case Nil $\Rightarrow$ Nil     case Cons(h, t) if p(h) $\Rightarrow$ Cons(h, filter(t, p))     case Cons(_, t) $\Rightarrow$ filter(t, p)  }  } def count(l: List, x: $Z$): $Z$ = {   decreases(l)   l match {     case Nil $\Rightarrow$ 0     case Cons(h, t) $\Rightarrow$ (if (h == x) 1 else 0)                   + count(t, x) }}

  ⬇   def partition(l: $List$,                 p: $Z\to Bool$): ($List$, $List$) = {     decreases($size\left(l\right)$)     l match {       case Nil $\Rightarrow$ Nil       case x :: xs $\Rightarrow$         val (l1, l2) = partition(xs, p)         if (p(x)) (x :: l1, l2)         else (l1, x :: l2) }   } ensuring { res $\Rightarrow$       res._1 == filter(l, p) &&       res._2 == filter(l, x $\Rightarrow$ !p(x))}

  ⬇ def partitionMultiplicity(@induct l: $List$, p: $Z\to Bool$, $x:Z$): Boolean = {   val (l1, l2) = partition(l, p)   count(l, x) == count(l1, x) + count(l2, x) } holds

  ⬇ def isSorted(l: List): Boolean = {   decreases(size(l))   l match {     case Nil() $\Rightarrow$ true     case Cons(x, Nil()) $\Rightarrow$ true     case Cons(x, Cons(y, ys)) $\Rightarrow$       x $\le$ y && isSorted(Cons(y, ys))   } }

  ⬇ def merge(l1: List, l2: List): List = {   require(isSorted(l1) && isSorted(l2))   decreases(size(l1) + size(l2))   (l1, l2) match {     case (Cons(x, xs), Cons(y, ys)) $\Rightarrow$       if (x $\le$ y) Cons(x, merge(xs, l2))       else Cons(y, merge(l1, ys))     case (Cons(_, _), Nil) $\Rightarrow$ l1     case _ => l2 } } ensuring { res => isSorted(res) }

  As an example, consider the list type as defined in Figure 3. We use $Z$ to denote the type of integers (corresponding to Scala’s BigInt in actual source code). The function filter filters elements from a list, while count counts the number of occurrences of an integer in the list. These two functions have no pre- or postconditions. The decreases clauses specify that the functions terminate because the size of the list decreases at each recursive call.

  Using these functions we define partition in Figure 3, which takes a list l of natural numbers and partitions it according to a predicate p: $Z\Rightarrow Bool$. We prove in the postcondition that partitioning coincides with applying filter to the list with p and its negation.

  Figure 4 shows a theorem that partition also preserves the multiplicity of each element. We use here count to state the property, but we could have used multisets instead (a type which is natively supported in Stainless). The holds keyword is a shorthand for ensuring { res => res }. The @induct annotation instructs the system to add a recursive call to partitionMultiplicity on the tail of l when l is not empty. This gives us access to the multiplicity property for the tail of l, which the system can then use automatically to prove that the property holds for l itself. This corresponds to a proof by induction on l.

  Figure 5 shows a function isSorted that checks whether a list is sorted, and a function merge that combines two sorted lists in a sorted list. When given the above input, the system proves the termination of all functions, establishes that postconditions of functions hold, and shows that the theorem holds, without any user interaction or additional annotations.

  2.1. Reasoning about Streams

  ⬇

  def constant[X](@ghost n: $Nat$, x: X): Stream[X](n) = {

    decreases(n)

    Stream(n)(x, $\left(\right)\Rightarrow$ constant[X](n-1,x))) }

  ⬇

  def zipWith[X,Y,Z](@ghost n: $Nat$, f: X $\Rightarrow$ Y $\Rightarrow$ Z, s1: Stream[X](n), s2: Stream[Y](n)): Stream[Z](n) = {

    decreases(n)

    Stream[Z](n)(f (s1.head) (s2.head), $\left(\right)\Rightarrow$ zipWith[X,Y,Z](n-1, f, s1.tail(), s2.tail()) ) }

  ⬇

  def fib(@ghost n: $Nat$): $Stream\left[Z\right]\left(n\right)$ = {

    decreases(n)

    Stream[$Z$](n)(0, $\left(\right)\Rightarrow$ Stream[$Z$](n-1)(1, $\left(\right)\Rightarrow$

      zipWith[$Z,Z,Z$](n-2, plus, fib(n-2), fib(n-1).tail()))) }

  Our system also supports reasoning about infinite data structures, including streams that are computed on demand. These data structures are challenging to deal with because even defining termination of an infinite stream is non-obvious, especially in absence of a concrete operation that uses the stream. Given some type X, $Stream\left[X\right]$ represents the type of infinite streams containing elements in X. In a mainstream call-by-value language such as Scala, this type can be defined as:

  ⬇

    case class Stream[X](head: X, tail: $Unit$ $\to$ Stream[X])

  For the sake of concise syntax, we typeset a function taking unit, (u:Unit)=>e, using Scala’s syntax $\left(\right)\Rightarrow$e for a function of zero parameters. Given a stream s: $Stream\left[X\right]$, we can call s.head to get the head of the stream (which is of type X), or s.tail to get the tail of the stream (which is of type $\left(\right)\Rightarrow Stream\left[X\right]$). We can use recursion to define streams, as shown in figures 8, 8, 8. The @ghost annotation is used to mark the ghost parameters n of these functions. These parameters are used as annotations to guide our type-checker, but they do not influence the computation and can be erased at runtime. For instance, an erased version of constant (without ghost code and without type annotation) looks like:

  ⬇

  def constant(x) = Stream(x, $\left(\right)\Rightarrow$ constant(x))

  Informally, we can say that the constant stream is terminating. Indeed, it has the interesting property that, despite the recursion, for every $n\in N$, we can take the first $n$ elements in finite time (no divergence in the computation). We say that constant(x) is an $n$-non-diverging stream. Moreover, when a stream is $n$-non-diverging for every $n\in N$, we simply say that it is non-diverging, which means that we can take as many elements as we want without diverging, which is the case for constant(x). Note that non-divergence of constant cannot be shown by defining a measure on its argument x that strictly decreases on each recursive call, because constant is called recursively on the exact same argument x. Instead, we define a measure on the ghost argument n of the annotated version. This corresponds to using type-based termination (Abel, 2008, 2007; Barthe et al., 2008), where the type of the function for the recursive call is smaller than the type of the caller. We expand on that technique in Section 5.2.

  In the annotated version of constant from Figure 8, the notation $Stream\left[X\right]\left(n\right)$ stands for streams of elements in X which are n-non-diverging. The type of constant then states that constant can be called with any (ghost) parameter n to build an n-non-diverging stream. Since parameter n is computationally irrelevant, this proves that the erased version of constant returns a non-diverging stream. At the moment, while our formalization fully supports streams, but we have not made Scala frontend modification for parameters such as $n$ to parse the functions given above. Instead we construct them internally in our tool as syntax trees.

  	$$t\text{Coloneqq}$$	$$x|\left(\right)|\lambda x.t|tt|(t,t)|{\pi }_{1}t|{\pi }_{2}t|$$
  		$$left\left(t\right)|right\left(t\right)|either\_match(t,x\Rightarrow t,x\Rightarrow t)|true|false|iftthentelset|$$
  		$$zero|succ\left(t\right)|rec(t,t,(n,y)\Rightarrow t)|fix\left(y\Rightarrow t\right)|match(t,t,n\Rightarrow t)$$
  		$$fold\left(t\right)|unfoldtinx\Rightarrow t|\Lambda t|t\left[\right]|err|refl|letx=tint|size\left(t\right)$$

  3. Syntax and Operational Semantics

  We now give a formal syntax for terms and show (in Appendix) call-by-value operational semantics. This untyped lambda calculus with pairs, tagged unions, integers, booleans, and error values models programs that our verification system supports. It is Turing complete and rather conventional.

  3.1. Terms of an Untyped Calculus

  Let $V$ be a set of variables. We let $Terms$ be the set of all (untyped) terms (see Figure 9) which includes the unit term $\left(\right)$, pairs, booleans, natural numbers, a recursor rec for iterating over natural numbers, a pattern matching operator match for natural numbers, a recursion operator fix, an error term $err$ to represent crashes, and a generic term $refl$ to represent proofs of equality between terms. The recursor rec can be simulated using fix and match but we keep it in the paper for presenting examples.

  The terms $fold\left(t\right)$ and $unfold{t}_{1}inx\Rightarrow t_2$ are used to represent data structures (such as lists or streams), where ‘$fold\left(\right)$’ plays the role of a constructor, and ‘$unfoldin$’ the role of a deconstructor. The terms $\Lambda t$ and $t\left[\right]$ are used to represent the erasure of type abstractions and type instantiation terms (for polymorphism) of the form $\Lambda \alpha .t$ and $t\left[\tau \right]$, where $\alpha$ is a type variable and $\tau$ is a type. These type-annotated terms will be introduced in a further section.

  The term $size\left(t\right)$ is a special term to internalize the sizes of syntax trees of values (ignoring lambdas) of our language. It is used for measure of recursive functions such as the map examples on lists shown in Section 2.

  Given a term $t$ we denote $fv\left(t\right)$ the set of all free variables of $t$. Terms are considered up to renaming of locally bound variables (alpha-renaming).

  3.2. Call-by-Value Operational Semantics

  The set $Val$ of values of our language is defined (inductively) to be $zero$, $\left(\right)$, $true$, $false$, $refl$, every variable $x$, every lambda term $\lambda x.t$ or $\Lambda t$, the terms of the form $succ\left(v\right)$ or $fold\left(v\right)$ where $v\in Val$, and the terms of the form $(v_1,v_2)$ where $v_1,v_2\in Val$.

  The call-by-value small-step relation between two terms $t_1,t_2\in Terms$, written $t_1\hookrightarrow t_2$, is standard for the most part and given in Figure 23 (Appendix A). Given a term $t$ and a value $v$, $t[x\mapsto v]$ denotes the term $t$ where every free occurrence of $x$ has been replaced by $v$.

  To evaluate the fixpoint operator fix, we use the rule $fix\left(y\Rightarrow t\right)\hookrightarrow t[y\mapsto \lambda \left(\right).fix\left(y\Rightarrow t\right)]$, which substitutes the fix under a lambda with unit argument. We do this wrapping of fix in a lambda term because we wanted all substitutions to be values for our call-by-value semantics, and fix is not. This also means that, to make a recursive call within $t$, one has to use y() instead of y.

  To define the semantics of $size\left(\right)$, we use a (mathematical) function $size\_semantics\left(\right)$ that returns the size of a value, ignoring lambdas for which it returns $0$. The precise definition is given in Figure 24 (Appendix A).

  We denote by ${\hookrightarrow }^{\ast }$ the reflexive and transitive closure of $\hookrightarrow$. A term $t$ is normalizing if there exists a value $v$ such that $t{\hookrightarrow }^{\ast }v$.

  	$$\tau \text{Coloneqq}$$	$$Unit|Bool|Nat|\top |\Pi x:\tau .\tau |\Sigma x:\tau .\tau |\tau +\tau |\forall x:\tau .\tau |\forall \alpha :Type.\tau$$

  4. Types, Semantics and Reducibility

  We give in Figure 10 the grammar for the types $\tau$ that our verification system supports. Given two types ${\tau }_1$ and ${\tau }_2$, we use the notation ${\tau }_1\to {\tau }_2$ for $\Pi x:{\tau }_1.{\tau }_2$ when $x$ is not a free variable of ${\tau }_2$. Similarly, we use the notation ${\tau }_1\times {\tau }_2$ when $x$ is not a free variable of ${\tau }_2$.

  For recursive types, we introduce the notation:

  $$Rec(\alpha \Rightarrow \tau )\equiv \forall n:Nat.Rec\left(n\right)(\alpha \Rightarrow \tau )$$

  Then, the type of (non-diverging) streams informally introduced in Section 2 can be understood as a notation, when X is a type, for: $Stream\left[X\right]\equiv Rec(\alpha \Rightarrow X\times (Unit\Rightarrow \alpha ))$. Similarly, for a natural number $n$, the type of $n$-non-diverging streams ${Stream}_n\left[X\right]$ is a notation for $Rec\left(n\right)(\alpha \Rightarrow X\times (Unit\Rightarrow \alpha ))$. Using this notation, we can also define finite data structures such as lists of natural numbers, as follows: $List\equiv Rec(\alpha \Rightarrow Unit+Nat\times \alpha )$.

  We show in Section 4.3 that these types indeed correspond to streams and lists respectively.

  Let $Type$ be the set of all types. We define a (unary) logical relation on types to describe terms that do not get stuck (e.g. due to the error term $err$, or due to an ill-formed application such as ‘$truezero$’) and that terminate to a value of the given type. Our definition is inspired by the notion of reducibility or hereditary termination (see e.g. (Tait, 1967; Girard, 1990; Harper, 2016)), which we use as a guiding principle for designing the type system and its extensions.

  4.1. Reduciblity for Closed Terms

  For each type $\tau$, we define in Figure 11 mutually recursively the sets of reducible values $\text{llbracket}\tau {\text{rrbracket}}_{\text{v}}^{\theta }$ and reducible terms $\text{llbracket}\tau {\text{rrbracket}}_{\text{t}}^{\theta }$. In that sense, a type $\tau$ can be understood as a specification that some terms satisfy (and some do not).

  These definitions require an environment $\theta$, called an interpretation, to give meaning to type variables. Concretely, an interpretation is a partial map from type variables to sets of terms. An interpretation $\theta$ has the constraint that for every type variable $\alpha \in dom\left(\theta \right)$, $\theta \left(\alpha \right)$ is a reducibility candidate $C$, which, in our setting, means that all terms in $\theta \left(\alpha \right)$ are (erased) values. The set of all reducibility candidates is denoted by $Candidates\subseteq 2^{Terms}$, and an interpretation $\theta$ is therefore a partial map in $V\mapsto Candidates$.

  When the interpretation has no influence on the definition, we may omit it. For instance, for every $\theta \in (V\mapsto Candidates)$, we have $\text{llbracket}Nat{\text{rrbracket}}_{\text{v}}^{\theta }=\{zero,succ(zero),succ(succ\left(zero\right)),\dots \}$, so we can just denote this set by $\text{llbracket}Nat{\text{rrbracket}}_{\text{v}}$.

  By construction, $\text{llbracket}\tau {\text{rrbracket}}_{\text{v}}^{\theta }$ only contains (erased) values (of type $\tau$), while $\text{llbracket}\tau {\text{rrbracket}}_{\text{t}}^{\theta }$ contains (erased) terms that reduce to a value in $\text{llbracket}\tau {\text{rrbracket}}_{\text{v}}^{\theta }$. For example, a term in $\text{llbracket}Nat\to Nat{\text{rrbracket}}_{\text{t}}^{\theta }$ is not only normalizing as a term of its own, but also normalizes whenever applied to a value in $\text{llbracket}Nat{\text{rrbracket}}_{\text{v}}^{\theta }$.

  	$$\text{llbracket}\alpha {\text{rrbracket}}_{\text{v}}^{\theta }=\theta \left(\alpha \right)$$
  	$$\text{llbracket}\top {\text{rrbracket}}_{\text{v}}^{\theta }=Val$$
  	$$\text{llbracket}Unit{\text{rrbracket}}_{\text{v}}^{\theta }=\left\{\left(\right)\right\}$$
  	$$\text{llbracket}Bool{\text{rrbracket}}_{\text{v}}^{\theta }=\{true,false\}$$
  	$$\text{llbracket}Nat{\text{rrbracket}}_{\text{v}}^{\theta }=\{zero,succ(zero),succ(succ\left(zero\right)),\dots \}$$
  	$$\text{llbracket}\Pi x:{\tau }_1.{\tau }_2{\text{rrbracket}}_{\text{v}}^{\theta }=\{f\in Val|\forall a\in \text{llbracket}{\tau }_1{\text{rrbracket}}_{\text{\% v}}^{\theta }.fa\in \text{llbracket}{\tau }_2[x\mapsto a\left]{\text{rrbracket}}_{\text{t}}^{\theta }\right\}$$
  	$$\text{llbracket}\forall x:{\tau }_1.{\tau }_2{\text{rrbracket}}_{\text{v\%}}^{\theta }=\{b\in Val|\forall a\in \text{llbracket}{\tau }_1{\text{rrbracket}}_{\text{v}}^{\theta }.b\in \text{llbracket}{\tau }_2[x\mapsto a\left]{\text{rrbracket}}_{\text{v}}^{\theta }\right\}$$
  	$$\text{llbracket}\Sigma x:{\tau }_1.{\tau }_2{\text{rrbracket}}_{\text{v}}^{\theta }\equiv \left\{\right(a,b)|a\in \text{llbracket}{\tau }_1{\text{rrbracket}}_{\text{v}}^{\theta }\wedge b\in \text{llbracket}{\tau }_2[x\mapsto a\left]{\text{rrbracket}}_{\text{\% v}}^{\theta }\right\}$$
  	$$\text{llbracket}\{x:\tau |b\}{\text{rrbracket}}_{\text{v}}^{\theta }=\{a\in \text{llbracket}\tau {\text{rrbracket}}_{\text{v}}^{\theta }|b[x\mapsto a\left]{\hookrightarrow }^{\ast }true\right\}$$
  	$$\text{llbracket}{\tau }_1+{\tau }_2{\text{rrbracket}}_{\text{v}}^{\theta }=\left\{left\right(v)|v\in \text{llbracket}{\tau }_1{\text{rrbracket}}_{\text{v}}^{\theta }\}\cup \left\{right\right(v)|v\in \text{llbracket}{\tau }_2{\text{rrbracket}}_{\text{v}}^{\theta }\}$$
  	$$\text{llbracket}{t}_1\equiv t_2{\text{rrbracket}}_{\text{v}}^{\theta }=\left\{refl\right\}\text{if}{t}_1\approx t_2\text{, and}\varnothing \text{otherwise, where}$$
  	$$(t_1\approx t_2)=(\forall v\in Val.\left(t_1{\hookrightarrow }^{\ast }viff{t}_2{\hookrightarrow }^{\ast }v\right))$$
  	$$\text{llbracket}\forall \alpha :Type.\tau {\text{rrbracket}}_{\text{\% v}}^{\theta }=\{v\in Val|\forall C\in Candidates.v[]\in \text{llbracket}\tau {\text{rrbracket}}_{\text{t}}^{\theta [\alpha \mapsto C]}\}$$
  	$$\text{llbracket}Rec\left(n\right)(\alpha \Rightarrow \tau ){\text{rrbracket}}_{\text{v}}^{\theta }=\{fold\left(v\right)|(n{\hookrightarrow }^{\ast }zero\wedge v\in \text{llbracket}{basetype}_{\alpha }(\tau \left){\text{rrbracket}}_{\text{v}}^{\theta }\right)\vee$$
  	$$\exists n^{\prime }\in \text{llbracket}Nat{\text{rrbracket}}_{\text{v}}.n{\hookrightarrow }^{\ast }succ\left(n^{\prime }\right)\wedge v\in \text{llbracket}\tau {\text{rrbracket}}_{\text{v}}^{\theta [\alpha \mapsto \text{llbracket}Rec\left(n^{\prime }\right)(\alpha \Rightarrow \tau ){\text{rrbracket}}_{\text{v}}^{\theta }]}\}$$
  	$$\text{llbracket}\tau {\text{rrbracket}}_{\text{t}}^{\theta }=\{t|\exists v\in \text{llbracket}\tau {\text{rrbracket}}_{\text{v}}^{\theta }.t{\hookrightarrow }^{\ast }v\}$$

  	$${basetype}_{\alpha }\left(\Sigma x:{\tau }_1.{\tau }_2\right)\equiv \Sigma x:{basetype}_{\alpha }\left({\tau }_1\right).{basetype}_{\alpha }\left({\tau }_2\right)$$
  	$${basetype}_{\alpha }\left({\tau }_1+{\tau }_2\right)\equiv {basetype}_{\alpha }\left({\tau }_1\right)+{basetype}_{\alpha }\left({\tau }_2\right)$$
  	$${basetype}_{\alpha }\left(\tau \right)\equiv \text{if}\alpha \in fv\left(\tau \right)\text{then}\top \text{else}\tau$$

  The type $\{x:\tau |b\}$ represents the values $v$ of type $\tau$ for which $b[x\mapsto v]$ evaluates to $true$. We use this type as a building block for writing specifications (pre and postconditions).

  The type $\forall x:{\tau }_1.{\tau }_2$ represents the values that are in the intersection of the types ${\tau }_2[x\mapsto v]$ when $v$ ranges over values of type ${\tau }_1$.

  The sum type ${\tau }_1+{\tau }_2$ represents values that are either of the form $left\left(v\right)$ where $v$ is a reducible value of ${\tau }_1$, or of the form $right\left(v\right)$ where $v$ is a reducible value of ${\tau }_2$.

  The set of reducible values for the equality type $\text{llbracket}{t}_1\equiv t_2{\text{rrbracket}}_{\text{v}}^{\theta }$ makes use of a notion of equivalence on terms which is based on operational semantics. More specifically, we say that $t_1$ and $t_2$ are equivalent, denoted $t_1\approx t_2$, if for every value $v$, we have $t_1{\hookrightarrow }^{\ast }viff{t}_2{\hookrightarrow }^{\ast }v$. Note that this equivalence relation is defined even if we do not know anything about the types of terms $t_1$ and $t_2$, and it ensures that if one of the terms reduces to a value, then so does the other.

  The type $\forall \alpha :Type.\tau$ is the polymorphic type from System F. The set $\text{llbracket}\forall \alpha :Type.\tau {\text{rrbracket}}_{\text{v}}^{\theta }$ is defined by using the environment $\theta$ to bind the type variable $\alpha$ to an arbitrary reducibility candidate.

  We use the recursive type $Rec\left(n\right)(\alpha \Rightarrow \tau )$ as a building block for representing data structures such as lists of streams. The definition of reducibility for the recursive type makes use of an auxiliary function $basetype\left(\right)$ that can be seen as an (upper) approximation of the recursive type. Note that ${basetype}_{\alpha }\left(\tau \right)$ removes the type variable $\alpha$ from $\tau$.

  Our reducibility definition respects typical lemmas that are needed to prove the soundness of typing rules, such as the following substitution lemma (see (Girard, 1971) for the lemma on System F), which we have formally proven (see also Section 5.8 below).

  Lemma 4.1 ().

  Let ${\tau }_1$ and ${\tau }_2$ be two types, and let $\alpha$ be a type variable that may appear in ${\tau }_1$ but not in ${\tau }_2$. Let $\theta$ be a type interpretation. Then, we have:

  $$\text{llbracket}{\tau }_1{\text{rrbracket}}_{\text{v}}^{\theta [\alpha \mapsto \text{llbracket}{\tau }_2{\text{rrbracket}}_{\text{v}}^{\theta }]}=\text{llbracket}{\tau }_1[\alpha \mapsto {\tau }_2]{\text{rrbracket}}_{\text{v}}^{\theta }$$

  4.2. Reduciblity for Open Terms

  Having defined reducibility for closed terms, we now define what it means for a term $t$ with free term and type variables to be reducible for a type $\tau$. Informally, we want to ensure that for every interpretation of the type variables, and for every substitution of values for the term variables, the term $t$ reduces in a finite number of steps to a value in type $\tau$. This is formalized by a (semantic) typing relation $\Theta ;\Gamma {\models }_{Red}t:\tau$ which is defined as follows.

  First, a context $\Theta ;\Gamma$ is made of a finite set $\Theta \subseteq V$ of type variables and of a sequence $\Gamma$ of pairs in $V\times Type$. The domain of $\Gamma$, denoted $dom\left(\Gamma \right)$ is the list of variables (in $V$) appearing in the left-hand-sides of the pairs. We implicitly assume throughout the paper that all variables appearing in the domains are distinct. This enables us to use $\Gamma$ as a partial map from $V$ to $Type$. We use a sequence to represent $\Gamma$ as the order of variables is important, since a variable may have a (dependent) type which refers to previous variables in the context.

  Given a partial map $\gamma \in V\mapsto Terms$, we write $\gamma \left(t\right)$ for the term $t$ where every variable $x$ is replaced by $\gamma \left(x\right)$. We use the same notation $\gamma \left(\tau \right)$ for applying a substitution to a type $\tau$.

  Given a context $\Theta ;\Gamma$, a reducible substitution for $\Theta ;\Gamma$ is pair a partial maps $\theta \in V\mapsto Candidates$ and $\gamma \in V\mapsto Terms$ where: $dom\left(\theta \right)=\Theta$, $dom\left(\gamma \right)=dom\left(\Gamma \right)$, and $\forall x\in dom\left(\Gamma \right).\gamma \left(x\right)\in \text{llbracket}\gamma \left(\Gamma \right(x\left)\right){\text{rrbracket}}_{\text{v}}^{\theta }$.

  Note that the substitution $\gamma$ is also applied to the type $\Gamma \left(x\right)$, since $\Gamma \left(x\right)$ may be a dependent type with free term variables. The set of all pairs of reducible substitutions for $\Theta ;\Gamma$ is denoted $\text{llbracket}\Theta ;\Gamma {\text{rrbracket}}_{\text{v}}$.

  Finally, given a context $\Theta ;\Gamma$, a term $t$ and a type $\tau$, we say that $\Theta ;\Gamma {\models }_{Red}t:\tau$ holds when for every pair of substitutions $\theta ,\gamma$ for the context $\Theta ;\Gamma$, $\gamma \left(t\right)$ belongs the reducible values at type $\gamma \left(\tau \right)$. Formally, $\Theta ;\Gamma {\models }_{Red}t:\tau$ is defined to hold when:

  $$\forall \theta ,\gamma \in \text{llbracket}\Theta ;\Gamma {\text{rrbracket}}_{\text{v}}.\gamma \left(t\right)\in \text{llbracket}\gamma \left(\tau \right){\text{rrbracket}}_{\text{t}}^{\theta }$$

  Our bidirectional type checking and inference algorithm in Section 5 is a sound (even if incomplete) procedure to check $\Theta ;\Gamma {\models }_{Red}t:\tau$.

  4.3. Recursive Types

  We explain in this section how to interpret the type $Rec\left(n\right)(\alpha \Rightarrow \tau )$ (see reducibility definition in Figure 11) and how the $Stream\left[X\right]$ and $List$ types represent streams and lists.

  4.3.1. Infinite Streams

  For a natural number $n$, consider the type $S_n\equiv {Stream}_{Nat}\left[n\right]\equiv Rec\left(n\right)(\alpha \Rightarrow Nat\times (Unit\Rightarrow \alpha ))$. Let us first see what $S_n$ represents for small values of $n$. As a shortcut, we use the notations $0$, $1$, $2$, $\dots$ for $zero$, $succ\left(zero\right)$, $succ\left(succ\left(zero\right)\right)$, $\dots$

  The definition $\text{llbracket}{S}_0{\text{rrbracket}}_{\text{v}}$ refers to ${basetype}_{\alpha }\left(Nat\times (Unit\Rightarrow \alpha )\right)$, which is $Nat\times \top$ by definition. This means that $\text{llbracket}{S}_0{\text{rrbracket}}_{\text{v}}$ is the set of values of the form $fold\left((a,v)\right)$, where $a\in \text{llbracket}Nat{\text{rrbracket}}_{\text{v}}$, and $v\in Val$.

  By unrolling the definition, we get that $\text{llbracket}{S}_1{\text{rrbracket}}_{\text{v}}$ is the set of values of the form $fold\left(v\right)$ where $v$ is in $\text{llbracket}Nat\times (Unit\Rightarrow \alpha ){\text{rrbracket}}_{\text{v}}^{[\alpha \mapsto \text{llbracket}{S}_0{\text{rrbracket}}_{\text{v}}]}$, which is the same (by Lemma 4.1) as $\text{llbracket}Nat\times (Unit\Rightarrow S_0){\text{rrbracket}}_{\text{v}}$. Therefore, $\text{llbracket}{S}_1{\text{rrbracket}}_{\text{v}}$ is the set of values of the form $fold\left(a,f\right)$ where $a\in \text{llbracket}Nat{\text{rrbracket}}_{\text{v}}$ and $f\in \text{llbracket}Unit\Rightarrow S_0{\text{rrbracket}}_{\text{v}}$. This means that when it is applied to $\left(\right)$, $f$ terminates and returns a value in $\text{llbracket}{S}_0{\text{rrbracket}}_{\text{v}}^{\theta }$. Similarly, $\text{llbracket}{S}_2{\text{rrbracket}}_{\text{v}}$ is the set of values of the form $fold\left(a,f\right)$ where $n\in \text{llbracket}Nat{\text{rrbracket}}_{\text{v}}$ and $f\in \text{llbracket}Unit\Rightarrow S_1{\text{rrbracket}}_{\text{v}}$.

  To summarize, we can say that for every $n\in \text{llbracket}Nat{\text{rrbracket}}_{\text{v}}$, $S_n$ represents values of the language that behave as streams of natural numbers, as long as they are unfolded at most $n+1$ times. This matches the property we mentioned in Section 2, as $S_n$ represents the streams that are $n+1$-non-diverging. We can show that as $n$ grows, $S_n$ gets more and more constraints: $\text{llbracket}{S}_0{\text{rrbracket}}_{\text{v}}\supseteq \text{llbracket}{S}_1{\text{rrbracket}}_{\text{v}}\supseteq \text{llbracket}{S}_2{\text{rrbracket}}_{\text{v}}\supseteq \dots$ In the limit, a value $v\in \text{llbracket}\forall n:Nat.S_n{\text{rrbracket}}_{\text{v}}$ (which is in every $S_n$ for $n\in \text{llbracket}Nat{\text{rrbracket}}_{\text{v}}$), represents a stream of natural numbers, that, regardless of the number of times it is unfolded, does not diverge, i.e. a non-diverging stream. Equivalently, we have $v\in \text{llbracket}Stream\left[Nat\right]{\text{rrbracket}}_{\text{v}}$.

  4.3.2. Finite Lists

  Types of the form $Rec(\alpha \Rightarrow \tau )$ can also be used to represent finite data structures such as lists. We let ${List}_n$ be a notation for $Rec\left(n\right)(\alpha \Rightarrow Unit+Nat\times \alpha )$, so that:

  $$List\equiv \forall n:Nat.{List}_n.$$

  Here are some examples to show how lists are encoded:

  • The empty list is $fold\left(left\left(\right)\right)$,

  • A list with one element $n$ is $fold\left(right\left(n,fold\left(left\left(\right)\right)\right)\right)$,

  • More generally, given an element $n$ and a list $l$, we can construct the list $n::l$ by writing: $fold\left(right\left(n,l\right)\right)$.

  Let us now see why $List$ represents the type of all finite lists of natural numbers. The first thing to note is that given $n\in \text{llbracket}Nat{\text{rrbracket}}_{\text{v}}$, ${List}_n$ does not represent the lists of size $n$. For instance, we know that $\text{llbracket}{List}_0{\text{rrbracket}}_{\text{v}}$ is the set of values of the form $fold\left(v\right)$ where $v\in \text{llbracket}{basetype}_{\alpha }\left(Unit+Nat\times \alpha \right){\text{rrbracket}}_{\text{v}}$, i.e. $v\in \text{llbracket}\top {\text{rrbracket}}_{\text{v}}=Val$. Therefore, ${List}_0$ contains lists of all sizes (and also all values that do not represent lists, such as $fold\left(zero\right)$ or $fold\left(\lambda x.(\left(\right)\right)$).

  Instead, ${List}_n$ can be understood as the values that, as long as they are unfolded no more than $n$ times, behave as lists. Just like for streams, we have: $\text{llbracket}{List}_0{\text{rrbracket}}_{\text{v}}\supseteq \text{llbracket}{List}_1{\text{rrbracket}}_{\text{v}}\supseteq \text{llbracket}{List}_2{\text{rrbracket}}_{\text{\% v}}\supseteq \dots$³³3This monotonicity comes from the fact that $\alpha$ only appear is positive positions in the definitions of the recursive types for streams and lists.

  In the limit, we can show that $List$ contains all finite lists, and nothing more.

  \thmt@toks\thmt@toks

  Let $v\in Val$ be a value. Then, $v\in \text{llbracket}List{\text{rrbracket}}_{\text{v}}$ if and only if there exists $k\ge 0$ and $a_1,\dots ,a_k\in \text{llbracket}Nat{\text{rrbracket}}_{\text{v}}$ such that $v=fold\left(right\left(a_1,\dots fold\left(right\left(a_k,fold\left(left\left(\right)\right)\right)\right)\dots \right)\right)$.

  Lemma 4.2 ().

  It can seem surprising that the type of streams $Rec(\alpha \Rightarrow Nat\times (Unit\Rightarrow \alpha ))$ contains infinite streams while the type of lists $Rec(\alpha \Rightarrow Unit+Nat\times \alpha )$ only contains finite lists. The reason is that, in a call-by-value language, a value representing an infinite list would need to have an infinite syntax tree, with infinitely many $fold\left(\right)$’s (which is not possible). On the other hand, we can represent infinite streams by hiding recursion underneath a lambda term as shown in Section 2.

  5. A Bidirectional Type-Checking Algorithm

  In this section, we give procedures for inferring a type $\tau$ for a term $t$ in a context $\Theta ;\Gamma$, denoted $\Theta ;\Gamma ⊢t\Uparrow \tau$, as well as for checking that the type of a term $t$ is $\tau$, denoted $\Theta ;\Gamma ⊢t\Downarrow \tau$. We introduce rules of our procedures throughout this section; the full set of rules is given in figures 12 and  13.

  $\Gamma \left(x\right)=\tau$   $\Theta ;\Gamma ⊢x\Uparrow \tau$ (Infer Var)   $\Theta ;\Gamma ⊢true\Uparrow Bool$ (Infer True)   $\Theta ;\Gamma ⊢false\Uparrow Bool$ (Infer False)   $\Theta ;\Gamma ⊢\left(\right)\Uparrow Unit$ (Infer Unit)   $\Theta ;\Gamma ⊢zero\Uparrow Nat$ (Infer Zero) $\Theta ;\Gamma ⊢t\Downarrow Nat$   $\Theta ;\Gamma ⊢succ\left(t\right)\Uparrow Nat$ (Infer Succ)

  $\Theta ;\Gamma ⊢t_1\Downarrow Bool$  $\Theta ;\Gamma ,p:t_1\equiv true⊢t_2\Uparrow {\tau }_2$  $\Theta ;\Gamma ,p:t_1\equiv false⊢t_3\Uparrow {\tau }_3$   $\Theta ;\Gamma ⊢if{t}_{1}then{t}_{2}else{t}_3\Uparrow If{t}_{1}Then{\tau }_{2}Else{\tau }_3$ (Infer If)

  $\Theta ;\Gamma ⊢t\Uparrow {\tau }_1+{\tau }_2$   $\Theta ;\Gamma ⊢left\left(t\right)\Uparrow {\tau }_1$ (Infer Left) $\Theta ;\Gamma ⊢t\Uparrow {\tau }_1+{\tau }_2$   $\Theta ;\Gamma ⊢right\left(t\right)\Uparrow {\tau }_2$ (Infer Right) $\Theta ;\Gamma ⊢t\Uparrow \tau$   $\Theta ;\Gamma ⊢size\left(t\right)\Uparrow Nat$ (Infer Size)

  $\Theta ;\Gamma ⊢t_n\Downarrow Nat$  $\Theta ;\Gamma ,p:t_n\equiv zero⊢t_0\Uparrow {\tau }_1$  $\Theta ;\Gamma ,n:Nat,p:t_n\equiv succ\left(n\right)⊢t_s\Uparrow {\tau }_2$   $\Theta ;\Gamma ⊢match(t_n,t_0,n\Rightarrow t_s)\Uparrow Match(t_n,{\tau }_1,n\Rightarrow {\tau }_2)$ (Infer Match)

  $\Theta ;\Gamma ⊢t\Uparrow {\tau }_1+{\tau }_2$  $\Theta ;\Gamma ,x:{\tau }_1,p:t\equiv left\left(x\right)⊢t_1\Uparrow {\tau }_1^{\prime }$  $\Theta ;\Gamma ,x:{\tau }_2,p:t\equiv right\left(x\right)⊢t_2\Uparrow {\tau }_2^{\prime }$   $\Theta ;\Gamma ⊢either\_match(t,x\Rightarrow t_1,x\Rightarrow t_2)\Uparrow Either\_Match(t,x\Rightarrow {\tau }_1^{\prime },x\Rightarrow {\tau }_2^{\prime })$ (Infer Either Match)

  $\begin{array}{c}\Theta ;\Gamma ⊢t_n\Downarrow Nat\Theta ;\Gamma ⊢t_0\Downarrow \tau [n\mapsto zero]\\ \Theta ;\Gamma ,n:Nat,y:Unit\to \tau ,p:y\equiv \lambda u:Unit.rec\left[n\to \tau \right](n,t_0,(n,y)\Rightarrow t_s)⊢t_s\Downarrow \tau [n\mapsto succ(n\left)\right]\end{array}$   $\Theta ;\Gamma ⊢rec\left[n\Rightarrow \tau \right](t_n,t_0,(n,y)\Rightarrow t_s)\Uparrow Letn=t_{n}in\tau$ (Infer Rec)

  $\begin{array}{c}n\notin fv\left(erase\left(t\right)\right)\\ \Theta ;\Gamma ,n:Nat,y:Unit\to \forall m:\{m:Nat|m<n\}.\tau [n\mapsto m],\\ p:y\equiv \lambda u:Unit.fix\left[n\Rightarrow \tau \right]\left((n,y)\Rightarrow t\right)⊢t[n\mapsto n]\Uparrow \tau \end{array}$   $\Theta ;\Gamma ⊢fix\left[n\Rightarrow \tau \right]\left((n,y)\Rightarrow t\right)\Uparrow \forall n:Nat.\tau$ (Infer Fix)

  $\Theta ;\Gamma ⊢t_1\Uparrow {\tau }_1$  $\Theta ;\Gamma ⊢t_2\Uparrow {}^{}$