Focusing on Refinement Typing

True, “well-typed programs cannot ‘go wrong’ ” [Milner 1978], but only relative to a given semantics (if the type system is proven sound with respect to it). Unfortunately, well-typed programs go wrong, in many ways that matter, but about which a conventional type system cannot speak: divisions by zero, out-of-bounds array accesses, information leaks. To prove a type system rules out (at compile time) more runtime errors, its semantics must be refined. However, there is often not enough type structure with which to express such semantics statically. So, we must refine our types with more information that tends to be related to programs. Great care is needed, though, because incorporating too much information (such as nonterminating programs themselves, as may happen in a dependent type system, where program terms may appear in types) can spoil good properties of the type system, such as type soundness or the decidability of type checking and inference.

Consider the inductive type \(\mathsf {List} \; A\) of lists with entries of type A. Such a list is either nil ( \([]\) ) or a term x of type A together with a tail list \(\mathit {xs}\) (that is, \(x :: \mathit {xs}\) ). In a typed functional language such as Haskell or OCaml, the programmer can define such a type by specifying its constructors:

Suppose we define, by pattern matching, the function get, which takes a list \(\mathit {xs}\) and a natural number y, and returns the yth element of \(\mathit {xs}\) (where the first element is numbered zero):

A conventional type system has no issue checking get against, say, the type \(\textsf {List} \; A \rightarrow \textsf {Nat} \rightarrow A\) (for any type A), but get is unsafe, because it throws an out-of-bounds error when the input number is greater than or equal to the length of the input list. If it should be impossible for get to throw such an error, then get must have a type where the input number is restricted to natural numbers strictly less than the length of the input list. Ideally, the programmer would simply refine the type of get, while leaving the program alone (except, perhaps, for omitting the first clause).

This, in contrast to dependent types [Martin-Löf 1984], is the chief aim of refinement types [Freeman and Pfenning 1991]: to increase the expressive power of a pre-existing (unrefined) type system, while keeping the latter’s good properties, such as type soundness and, especially, decidability of typing, so programmers are not too burdened with refactoring their code or manually providing tedious proofs. In other words, the point of refinement types is to increase the expressive power of a given type system while maintaining high automation (of typing for normal programs), whereas the point of dependent types is to be maximally expressive (even with the ambitious aim of expressing all mathematics), at the cost of automation (which dependent type system designers may try to increase after the fact of high expressivity).

To refine get’s type to rule out, statically, runtime out-of-bounds errors, we need to compare numbers against list lengths. Thus, we refine the type of lists by their length: \({\left\lbrace {\nu : \textsf {List} \; A} \;\middle |\; {\textsf {len} \; \nu = n}\right\rbrace }\) , the type of lists \(\nu\) of length n. This type looks a bit worrying, though, because the measurement, \(\textsf {len} \; \nu = n\) , seems to use a recursive program, len. The structurally recursive

happens to terminate when applied to lists, but there is no general algorithm for deciding whether an arbitrary computation terminates [Turing 1936]. As such, we would prefer not to use ordinary recursive programs at all in our type refinements. Indeed, doing so would seem to violate a phase distinction¹ [Moggi 1989a; Harper et al. 1990] between static (compile time) specification and dynamic (runtime) program, which is almost indispensable for decidable typing.

The refinement type system Dependent ML (DML) [Xi 1998] provides a phase distinction in refining ML by an index domain that has no runtime content.² Type checking and inference in DML is only decidable when it generates constraints whose satisfiability is decidable. In practice, DML did generate decidable constraints, but that was not guaranteed by its design. DML’s distinction between indexes and programs allows it to support refinement types in the presence of computational effects (such as nontermination, exceptions, and mutable references) in a relatively straightforward manner. Further, the index-program distinction clarifies how to give a denotational semantics: A refinement type denotes a subset of what the type’s erasure (of indexes) denotes and a program denotes precisely what its erasure denotes [Melliès and Zeilberger 2015]. Dependent type systems, by contrast, do not have such an erasure semantics.

It seems liquid type systems [Rondon et al. 2008; Kawaguchi et al. 2009; Vazou et al. 2013;, 2014] achieve highly expressive, yet sound and decidable recursive refinements [Kawaguchi et al. 2009] of inductive types by a kind of phase distinction: namely, by restricting the recursive predicates of specifications to terminating measures (like len) that soundly characterize, in a theory decidable by off-the-shelf tools like SMT solvers, the static structure of inductive types. Unlike DML, liquid typing can, for example, use the measure of whether a list of natural numbers is in increasing order, while remaining decidable. However, liquid typing’s lack of index-program distinction makes it unclear how to give it a denotational semantics and has also led to subtleties involving the interaction between effects and evaluation strategy (we elaborate later in this section and Section 2). Vazou et al. [2014] appear to provide a denotational semantics in Section 3.3, but this is not really a denotational semantics in the sense we intend, because it is defined in terms of an operational semantics and not a separate and well-established mathematical model (such as domain theory).

Let us return to the \(\mathsf {get}\) example. Following the tradition of index refinement [Xi 1998], we maintain a phase distinction by syntactically distinguishing index terms, which can safely appear in types, from program terms, which cannot. In this approach, we want to check get against a more informative type

quantifying over indexes l of sort \(\mathbb {N}\) (natural numbers) and requiring the accessing number to be less than l. However, this type is not quite right, because Nat is a type and \(\mathbb {N}\) is a sort, so writing “ \(\nu \lt l\) ” confounds our phase distinction between programs and indexes. Instead, the type should look more like

where

computes the index term of sort \(\mathbb {N}\) that corresponds to a program term of type Nat, by a structural recursion homologous to that of len. The third clause of get has a nonempty list as input, so its index (length) must be \(1 + m\) for some m; the type checker assumes \(\textsf {index} \, (\textsf {succ} \, y) \lt 1 + m\) ; by the aforementioned homology, these constraints are again satisfied at the recursive call ( \(\mathsf {index} \, y \lt m\) ), until the second clause returns ( \(0 \lt 1 + m^{\prime }\) ). The first clause of get is impossible, because no natural number is less than zero. We can therefore safely remove this clause, or (equivalently) replace error with unreachable, which checks against any type under a logically inconsistent context, such as \(l:\mathbb {N}, n:\mathbb {N}, l = 0, n \lt l\) in this case.

Applying get to a list and a number determines the indexes l and n. We say that l and n are value-determined (here, by applying the function to values). If (perhaps in a recursive call) get is called with an empty list \([]\) and a natural number, then l is determined to be 0, and, since no index that is both negative and a natural number exists, no out-of-bounds error can arise by calling get. (Further, because \(l : \mathbb {N}\) strictly decreases at recursive calls, calling \(\mathsf {get}\) terminates.)

While this kind of reasoning about get’s type refinement may seem straightforward, how do we generalize it to recursion over any algebraic datatype (ADT)? What are its logical and semantic ingredients? How do we use these ingredients to concoct a type system with decidable typing, good (localized) error messages, and so on, while also keeping its metatheory relatively stable or maintainable under various extensions or different evaluation strategies?

Type systems that can do this kind of reasoning automatically, especially in a way that can handle any evaluation strategy, are hard to design correctly. Indeed, the techniques used in the original (call-by-value) liquid type system(s) [Rondon et al. 2008; Kawaguchi et al. 2009] had to be modified for Haskell, essentially because of Haskell’s call-by-name evaluation order [Vazou et al. 2014]. The basic issue was that binders can bind in (static) refinement predicates, which is fine when binders only bind values (as in call-by-value), but not when they bind computations that may not terminate (as in call-by-name). Liquid Haskell regained (operational) type soundness by introducing ad hoc restrictions that involve approximating whether binders terminate and using the refinement logic to verify termination.

We design a foundation on which to build liquid typing features that allows us to establish clear (semantic) soundness results, as well as the completeness of a decidable bidirectional typing algorithm. The main technique facilitating this is focusing, which we combine with bidirectional typing and value-determined indexes (the latter being a key ingredient to make measures work). In other words, this article is a first step toward reconciling DML and Liquid Haskell, using the proof-theoretic technique of focusing.

Andreoli [1992] introduced focusing to reduce the search space for proofs (programs) of logical formulas (types) by exploiting the property that some inference rules are invertible (the rule’s conclusion implies its premises). In relation to functional programming, focusing has been used, for example, to explain features such as pattern matching [Krishnaswami 2009], to explain the interaction between evaluation order and effects [Zeilberger 2009], and to reason about contextual program equivalence [Rioux and Zdancewic 2020]. Focusing has been applied to design a union and intersection refinement typing algorithm [Zeilberger 2009]. As far as we know, until now focusing has not been used to design an index refinement typing algorithm. By focusing on the typing of function argument lists and results, our focused system guarantees that value-determined existential indexes (unification variables) are solved before passing constraints to an SMT solver. For example, when our system infers a type for \(\mathsf {get} ([3,1,2], 2)\) , we first use the top-level annotation of \(\mathsf {get}\) to synthesize the type

(in which we have added polarity shifts \({\downarrow \!{-}}\) and \({\uparrow \!{-}}\) arising from focusing). The downshift \({\downarrow \!{-}}\) takes a negative type to a positive type of suspended computations. Second, we check the argument list ( \([3,1,2], 2\) ) against the negative (universally quantified) type. The upshift \({\uparrow \!{-}}\) takes a positive type A to negative type \({\uparrow \!{A}}\) (computations returning a value of type A). In typechecking the argument list, the upshift signifies the end of a (left) focusing stage, at which point the first argument value \([3,1,2]\) will have determined l to be 3 and the second argument value 2 will have determined n to be 2, outputting an SMT constraint without existentials: \(2 \lt 3\) .

Levy [2004] introduced the paradigm and calculus call-by-push-value(CBPV), which puts both call-by-name and call-by-value on equal footing in the storm of computational effects (such as nontermination). CBPV subsumes both call-by-name (CBN) and call-by-value (CBV) functional languages, because it allows us to encode both via type discipline. In particular, CBPV polarizes types into (positive) value types P and (negative) computation types N and provides polarity shifts \({\uparrow \!{P}}\) (negative) and \({\downarrow \!{N}}\) (positive); the monads functional programmers use to manage effects arise as the composite \({\downarrow \!{{\uparrow \!{-}}}}\) . These polarity shifts are the same as those arising from focusing. CBPV can be derived logically by way of focalization [Espírito Santo 2017], which we did in our system. Focalized CBPV is a good foundation for a refinement typing algorithm: Designing refinement typing algorithms is challenging and sensitive to effects and evaluation strategy, so it helps to refine a language that makes evaluation order explicit. We leverage focusing and our technique of value-determined indexes (a novelty in the DML tradition) to guarantee (like Liquid Haskell) the generation of SMT-solvable constraints.

Bidirectional typing [Pierce and Turner 2000] systematizes the difference between input (for example, type checking) and output (for example, type inference) and seems to fit nicely with focused systems [Dunfield and Krishnaswami 2021]. Bidirectional typing has its own practical virtues: It is easy to implement (if inputs and outputs fit together properly, that is, if the system is well-moded); it scales well (to refinement types, higher-rank polymorphism [Dunfield and Krishnaswami 2019], subtyping, effects—and so does CBPV); it leads to localized error messages; and it clarifies where type annotations are needed, typically in reasonable positions (such as at the top level) that are helpful as machine-checked documentation. In our system, annotations are needed only for recursive functions (to express termination refinements) and top-level definitions.

A focused and bidirectional approach therefore appears suitable, both theoretically and practically, for systematically designing and implementing an expressive language of type refinement that can handle any evaluation strategy and effect. We show that bidirectional typing and logical focusing work very well together at managing the complex flow of information pertaining to indexes of recursive data. In particular, value-determined existential indexes of input types are solved within focusing stages, ultimately leading to the output of constraints (and types) in the quantifier-free fragment solvable by SMT solvers.

Contributions. Our two key contributions are both a declarative/logical/semantic and an algorithmic account of recursive, index-based refinement of algebraic data types. For the logical account, we design a declarative type system in a bidirectional and focused style, resulting in a system with clear denotational semantics and soundness proofs and which is convenient for type theorists of programming languages. The declarative system conjures index solutions to existentials. For the algorithmic account, we design a type system similar to the declarative one but solving all existentials and prove it is decidable as well as sound and complete. We contribute:

We relatively easily obtain both semantic and algorithmic results for a realistic language essentially by applying just one technique (based on fundamental logical principles): focusing.

All proofs are in the appendix.

This article is a first step toward reconciling Dependent ML and Liquid Haskell. The main thing we get from DML is the index-program distinction. Liquid Haskell provides or inspires three things. First, the observation of difficulties with effects and evaluation order inspired our use of CBPV. Second, we study (nullary) measures (supporting multi-argument measures is ongoing work). Third, our technique of value-determined indexes was inspired by the observation that variables appearing in liquid refinements correspond to inputs or outputs of functions.

Before diving into the details of our type system, we give an overview of the central logical, semantic, and algorithmic issues informing its design. The main technique we use to easily support both semantic and algorithmic results is focalization.

Refinement typing, evaluation strategy, and computational effects. The interactions between refinement typing (and other fancy typing), evaluation strategy, and computational effects are a source of peril. The combination of parametric polymorphism with effects is often unsound [Harper and Lillibridge 1991]; the value restriction in Standard ML recovers soundness in the presence of mutable references by restricting polymorphic generalization to syntactic values [Wright 1995]. The issue was also not peculiar to polymorphism: Davies and Pfenning [2000] discovered that a similar value restriction recovers type soundness for intersection refinement types and effects in call-by-value languages. For union types, Dunfield and Pfenning [2003] obtained soundness by an evaluation context restriction on union elimination.

For similar reasons, Liquid Haskell was also found unsound in practice and had to be patched; we adapt an example [Vazou et al. 2014] demonstrating the discovered unsoundness:

In typechecking unsafe, we need to check that the type of y (a singleton type of one value: 0) is a subtype of safediv’s second argument type (under the context of the let-binding). Due to the refinement of the let-bound notused, this subtyping generates a constraint or verification condition of the form “if false is true, then...” This constraint holds vacuously, implying that unsafe is safe. But unsafe really is unsafe, because Haskell evaluates lazily: Since notused is not used, diverge is never called, and hence safediv divides by zero (and crashes if uncaught). Vazou et al. [2014] recover type soundness and decidable typing by restricting let-binding and subtyping, using an operational semantics to approximate whether or not expressions diverge and whether or not terminating terms terminate to a finite value.

The value and evaluation context restrictions seem like ad hoc ways to cope with the failure of simple typing rules to deal with the interactions between effects and evaluation strategy. However, Zeilberger [2009] explains the value and evaluation context restrictions in terms of a logical view of refinement typing. Not only does this perspective explain these restrictions, it provides theoretical tools for designing type systems for functional languages with effects. At the heart of Zeilberger’s approach is the proof-theoretic technique of focusing, which we discuss near the end of this overview. An important question we address is whether polarization and focusing can also help us understand Liquid Haskell’s restrictions on let-binding and subtyping: Basically, our let-binding rule requires the bound computation (negative type) to terminate to a value (positive type). In other words, focalized systems satisfy any necessary value (and covalue) restrictions by default. We discuss this further in Section 8.

Focalization can also yield systems with good semantic properties under computational effects, in particular, variants of call-by-push-value.

Refining call-by-push-value. Call-by-push-value [Levy 2004] subsumes both call-by-value and call-by-name by polarizing the usual terms and types of the \(\lambda\) -calculus into a finer structure that can be used to encode both evaluation strategies in a way that can accommodate computational effects: value (or positive) types (classifying terms that “are,” that is, values v), computation (or negative) types (classifying terms that “do,” that is, expressions e), and polarity shifts \({\uparrow \!{-}}\) and \({\downarrow \!{-}}\) between them. An upshift \({\uparrow \!{P}}\) lifts a (positive) value type P up to a (negative) computation type of expressions that compute values (of type P). A downshift \({\downarrow \!{N}}\) pushes a (negative) computation type N down into a (positive) value type of thunked or suspended computations (of type N). We can embed the usual \(\lambda\) -calculus function type \(A \rightarrow _\lambda B\) (written with a subscript to distinguish it from the CBPV function type), for example, into CBPV (whose function types have the form \(P \rightarrow N\) for positive P and negative N) so it behaves like CBV, via the translation \(\iota _{\text{CBV}}\) with \(\iota _{\text{CBV}}(A \rightarrow _\lambda B) = {\downarrow \!{(\iota _{\text{CBV}}(A) \rightarrow {\uparrow \!{\iota _{\text{CBV}}(B)}})}}\) ; or so it behaves like CBN, via the translation \(\iota _{\text{CBN}}\) with \(\iota _{\text{CBN}}(A \rightarrow _\lambda B) = ({\downarrow \!{\iota _{\text{CBN}}(A)) \rightarrow \iota _{\text{CBN}}(B)}}\) .

Evaluation order is made explicit by CBPV type discipline. Therefore, adding a refinement layer on top of CBPV requires directly and systematically dealing with the interaction between type refinement and evaluation order. If we add this layer to CBPV correctly from the very beginning, then we can be confident that our type refinement system will be semantically well-behaved when extended with other computational effects. The semantics of CBPV are well-studied and this helps us establish semantic metatheory. In later parts of this overview, we show the practical effects of refining our focalized variant of CBPV, especially when it comes to algorithmic matters.

Type soundness, totality, and logical consistency. The unrefined system underlying our system has the computational effect of nontermination and hence is not total. To model nontermination, we give the unrefined system an elementary domain-theoretic denotational semantics. Semantic type soundness says that a syntactic typing derivation can be faithfully interpreted as a semantic typing derivation, that is, a morphism in a mathematical category, in this case a logical refinement of domains. Semantic type soundness basically corresponds to syntactic type soundness with respect to a big-step operational semantics. While we do not provide an operational semantics in this article, we do prove a syntactic substitution lemma that would be a key ingredient to prove that an operational semantics preserves typing (beta reduction performs syntactic substitution). The substitution lemma is also helpful to programmers, because it means they can safely perform program transformations and preserve typing. Because the unrefined system is (a focalized variant of) CBPV, proving type soundness is relatively straightforward.

In contrast to dependent types, the denotational semantics of our refined system is defined in terms of that of its erasure (of indexes), that is, its underlying, unrefined system. A refined type denotes a logical subset of what its erasure denotes. An unrefined return type \({\uparrow \!{P}}\) denotes either what P denotes or divergence/nontermination. A refined return type \({\uparrow \!{P}}\) denotes only what P denotes. Therefore, our refined type soundness result implies that our refined system (without a partial upshift type) enforces termination. The refined system can be extended (by a partial upshift type) to permit divergence while keeping type soundness (which implies partial correctness for partial upshifts). Type soundness also implies logical consistency, because a logically inconsistent refinement type denotes the empty set. We also prove that syntactic substitution is semantically sound, which would be a main lemma in proving that an operational semantics is equivalent to our denotational semantics.

In Section 5, we discuss these semantic issues in more detail.

Algebraic data types and measures. A novelty of liquid typing is the use of measures: functions, defined on algebraic data types, which may be structurally recursive, but are guaranteed to terminate and can therefore safely be used to refine the inductive types over which they are defined. (In this article, we only consider nullary measures.)

For example, consider the type \(\mathsf {BinTree} \; A\) of binary trees with terms of type A at leaves:

Suppose we want to refine \(\mathsf {BinTree} \; A\) by the height of trees. Perhaps the most direct way to specify this is to measure it using a function hgt defined by structural recursion:

As another example, consider an inductive type \(\mathsf {Expr}\) of expressions in a CBV lambda calculus:Measures need not involve recursion. For example, if we want to refine the type \(\mathsf {Expr}\) to expressions \(\mathsf {Expr}\) that are values (in the sense of CBV, not CBPV), then we can use \(\mathsf {isval}\) :

Because \(\mathsf {isval}\) is not recursive and returns indexes, it is safe to use it to refine \(\mathsf {Expr}\) to expressions that are CBV values: \({\left\lbrace {\nu : \mathsf {Expr}} \;\middle |\; {\mathsf {isval} \; \nu = \mathsf {tt}}\right\rbrace }\) . But, as with len (Section 1), we may again be worried about using the seemingly dynamic, recursively defined \(\mathsf {hgt}\) in a static type refinement. Again, we need not worry, because hgt, like len, is a terminating function into a decidable logic [Barrett et al. 2009]. We can use it to specify that, say, a height function defined by pattern matching on trees of type \({\left\lbrace {\nu : \mathsf {BinTree} \; A} \;\middle |\; {\mathsf {hgt} \; \nu = n}\right\rbrace }\) actually returns (the program value representing) n for any tree of height n. Given the phase distinction between indexes (like n) and programs, how do we specify such a function type? We use refinement type unrolling and singletons.

Unrolling and singletons. Let us consider a slightly simpler function, length, that takes a list and returns its length:

What should be the type specifying that length actually returns a list’s length? The proposal \(\forall {n:\mathbb {N}}.\: \textsf {List}(A)(n) \rightarrow {\uparrow \!{\textsf {Nat}}}\) does not work, because Nat has no information about the length n. Something like \(\forall {n:\mathbb {N}}.\: \textsf {List}(A)(n) \rightarrow {\uparrow \!{(n : \textsf {Nat})}}\) , read literally as returning the index n, would violate our phase distinction between programs and indexes. Instead, we use a singleton type in the sense of Xi [1998]: A singleton type contains just those program terms (of the type’s erasure) that correspond to exactly one semantic index. For example, given \(n:\mathbb {N}\) , we define the singleton type \(\textsf {Nat}(n)\) (which may also be written \(\textsf {Nat} \; n\) ) by \({\left\lbrace {\nu : \mathsf {Nat}} \;\middle |\; {\mathsf {index}\,{\nu } = n}\right\rbrace }\) where

specifies the indexes (of sort \(\mathbb {N}\) ) corresponding to program values of type \(\mathsf {Nat}\) .

How do we check length against \(\forall {n:\mathbb {N}}.\: \textsf {List}(A)(n) \rightarrow {\uparrow \!{(\mathsf {Nat}({n}))}}\) ? In the first clause, the input [] has type \(\textsf {List}(A)(n)\) for some n, but we need to know \(n=0\) (and that the index of zero is 0). Similarly, we need to know \(x :: \mathit {xs}\) has length \(n = 1 + n^{\prime }\) where \(n^{\prime } : \mathbb {N}\) is the length of \(\mathit {xs}\) . To generate these constraints, we use an unrolling judgment (Section 4.6) that unrolls a refined inductive type. Unrolling puts the type’s refinement constraints, expressed by asserting and existential types, in the structurally appropriate positions. An asserting type is written \(P \wedge \phi\) (read “P with \(\phi\) ”), where P is a (positive) type and \(\phi\) is an index proposition. If a term has type \(P \wedge \phi\) , then the term has type P and also \(\phi\) holds. (Dual to asserting types, we have the guarded type \(\phi \mathrel {\supset }N\) , which is equivalent to N if \(\phi\) holds, but is otherwise useless.) We use asserting types to express that index equalities like \(n=0\) hold for terms of inductive type. We use existentials to quantify over indexes that characterize the refinements of recursive subparts of inductive types, like \(n^{\prime }\) . For example, modulo a small difference (see Section 4.6), \(\textsf {List}(A)(n)\) unrolls to

That is, to construct an A-list of length n, the programmer (or library designer) can either left-inject a unit value, provided the constraint \(n=0\) holds, or right-inject a pair of one A value and a tail list, provided that \(n^{\prime }\) , the length of the tail list, is \(n - 1\) (the equations \(n = 1 + n^{\prime }\) and \(n - 1 = n^{\prime }\) are equivalent). These index constraints are not a syntactic part of the list itself. That is, a term of the above refined type is also a term of the type’s erasure (of indexes):where \(| - |\) erases indexes. Dual to verifying refined inductive values, pattern matching on refined inductive values, such as in the definition of length, allows us to use the index refinements locally in the bodies of the various clauses for different patterns. Liquid Haskell similarly extracts refinements of data constructors for use in pattern matching.

The shape of the refinement types generated by our unrolling judgment (such as the one above) is a judgmental and refined-ADT version of the fact that generalized ADTs (GADTs) can be desugared into types with equalities and existentials that express constraints of the return types for constructors [Cheney and Hinze 2003; Xi et al. 2003]. It would be tedious and inefficient for the programmer to work directly with terms of types produced by our unrolling judgment, but we can implement (in our system) singleton refinements of base types and common functions on them, such as addition, subtraction, multiplication, division, and the modulo operation on integers, and build these into the surface language used by the programmer, similarly to the implementation of Dependent ML [Xi 1998].

Inference and subtyping. For a typed functional language to be practical, it must support some degree of inference, especially for function application (to eliminate universal types) and constructing values (to introduce existential types). For example, to pass a value to a function, its type must be compatible with the function’s argument type, but it would be burdensome to make programmers always have to prove this compatibility. In our setting, for example, if \(x : \textsf {Nat}(3)\) and \(f : {\downarrow \!{(\forall {a:\mathbb {N}}.\: \textsf {Nat}(a) \rightarrow {\uparrow \!{P}})}}\) , then we would prefer to write \(f\;x\) rather than \(f\;[3]\;x\) , which would quickly make our programs incredibly—and unnecessarily—verbose.

Omitting index and type annotations, however, has significant implications. In particular, we need a mechanism to instantiate indexes somewhere in our typing rules: For example, if \(g : {\downarrow \!{({\downarrow \!{(\textsf {Nat}(4+b) \rightarrow {\uparrow \!{P}})}} \rightarrow N)}}\) and \(h : {\downarrow \!{((\exists {a:\mathbb {N}}.\: \textsf {Nat}(a)) \rightarrow {\uparrow \!{P}})}}\) , then to apply g to h, we need to know \(\textsf {Nat}(4+b)\) is compatible with \(\exists {a:\mathbb {N}}.\: \textsf {Nat}(a)\) , which requires instantiating the bound a to a term logically equal to \(4+b\) . Our system does this kind of instantiation via subtyping, which refinement types naturally give rise to: A type refinement is essentially a subtype of its erasure. Index instantiations are propagated locally across adjacent nodes in the syntax tree, similarly to Pierce and Turner [2000]. (Liquid typing allows for more inference, including inference of refinements based on templates, which provides additional convenience for programmers, but we do not consider this kind of inference in this article.)

We polarize subtyping into two, mutually recursive, positive and negative relations \({\Theta }\vdash{P}\leq^{+}{Q}\) and \({\Theta }\vdash{N}\leq^{-}{M}\) (where \(\Theta\) is a logical context including index propositions). The algorithmic versions of these only introduce existential variables in positive supertypes and negative subtypes, guaranteeing they can always be solved by indexes without any existential variables. We delay checking constraints until the end of certain, logically designed stages (the focusing ones, as we will see), when all of their existential variables are guaranteed to have been solved.

Value-determined indexes and type well-formedness. Like DML, we have an index-program distinction, but unlike DML and like Liquid Haskell, we want to guarantee SMT solvable constraints. We accomplish this with our technique of value-determined indexes. To guarantee that our algorithm can always instantiate quantifiers, we restrict quantification to indexes appearing in certain positions within types: namely, those that are uniquely determined (semantically speaking) by values of the type, both according to a measure and before crossing a polarity shift (which in this case marks the end of a focusing stage). For example, in \({\left\lbrace {\nu : \textsf {List} \; A} \;\middle |\; {\textsf {len}\,{\nu } = b}\right\rbrace }\) , the index b is uniquely determined by values of that type: The list \([x, y]\) uniquely determines b to be 2 (by the length measure). This value-determinedness restriction on quantification has served to explain why a similar restriction in the typing algorithm of Flux (Liquid Rust) seemed to work well in practice [Lehmann et al. 2023].

We make this restriction in the type well-formedness judgment, which outputs a context \(\Xi\) tracking value-determined indexes; well-formed types can only quantify over indexes in \(\Xi\) . For example, \(\exists {b:\mathbb {N}}.\: {\left\lbrace {\nu : \textsf {List} \; A} \;\middle |\; {\textsf {len}\,{\nu } = b}\right\rbrace }\) is well-formed. The variables in \(\Xi\) also pay attention to type structure: For example, a value of a product type is a pair of values, where the first value determines all \(\Xi _1\) (for the first type component) and the second value determines all \(\Xi _2\) (second type component), so the \(\Xi\) of the product type is their union \(\Xi _1 \cup \Xi _2\) . We also take the union for function types \(P \rightarrow N\) , because index information flows through argument types toward the return type, marked by a polarity shift.

By emptying \(\Xi\) at shift types, we prevent lone existential variables from being introduced at a distance, across polarity shifts. In practice, this restriction on quantification is not onerous, because most functional types that programmers use are, in essence, of the form

where the “ \(\forall\) ” quantifies over indexes of argument types \(P_k\) that are uniquely determined by argument values, and the “ \(\exists\) ” quantifies over indexes of the return type that are determined by (or at least depend on) fully applying the function and thereby constructing a value to return. The idea of this restriction was inspired by liquid types, because they implicitly follow it: Variables appearing in liquid type refinements must ultimately come from arguments x to dependent functions \(x\!:\!A \rightarrow B\) and their return values (however, these are not explicitly index variables).

Types that quantify only across polarity shifts tend to be empty, useless, or redundant. The ill-formed type \(\forall {n:\mathbb {N}}.\: 1 \rightarrow {\uparrow \!{\mathsf {Nat}({n})}}\) is empty because no function returns all naturals when applied to unit. A term of ill-formed type \(\exists {m:\mathbb {N}}.\: {\downarrow \!{(\mathsf {Nat}({m}) \rightarrow {\uparrow \!{\mathsf {Bool}}}}})\) can only be applied to an unknown number, which is useless because the number is unknown. The ill-formed type \(\exists {n:\mathbb {N}}.\: {\uparrow \!{{\downarrow \!{\mathsf {Nat}({n})}}}}\) is redundant because it is semantically equivalent to \({\downarrow \!{{\uparrow \!{\exists {n:\mathbb {N}}.\: \mathsf {Nat}({n})}}}}\) (which does not quantify across a polarity shift), and similarly \(\forall {n:\mathbb {N}}.\: {\uparrow \!{{\downarrow \!{(\mathsf {Nat}({n}) \rightarrow {\uparrow \!{\mathsf {Nat}({n})}})}}}}\) is semantically equivalent to \({\uparrow \!{{\downarrow \!{(\forall {n:\mathbb {N}}.\: \mathsf {Nat}({n}) \rightarrow {\uparrow \!{\mathsf {Nat}({n})}})}}}}\) . Some refinements are not value-determined but useful nonetheless, such as dimension types [Kennedy 1994; Dunfield 2007b] that statically check that dimensions are used consistently (minutes can be added to minutes, but not to kilograms) but do not store the dimensions at runtime. In this article, we do not consider these non-value-determined refinements, and Liquid Haskell does not support them either.

Our value-determinedness restriction on type well-formedness, together with focusing, is very helpful metatheoretically, because it means that our typing algorithm only introduces—and is guaranteed to solve—existential variables for indexes within certain logical stages. For example, consider checking a list against \(\exists {b:\mathbb {N}}.\: {\left\lbrace {\nu : \textsf {List} \; A} \;\middle |\; {\textsf {len}\,{\nu } = b}\right\rbrace }\) . An existential variable \(\hat{b}\) for b is generated, and we check the unrolled list against the unrolling of \({\lbrace {\nu : \textsf {List} \; A} \; |\; {\textsf {len}\,{\nu } = \hat{b}}\rbrace }\) . A solution to \(\hat{b}\) will be found within value typechecking (the right-focusing stage), using the invariant that no measure (such as \(\textsf {len}\) ) contains any existential variables. Similarly, applying a function with universal quantifiers will solve all existential variables arising from these quantifiers by the end of a left-focusing stage, which typechecks an argument list.

Focusing, CBPV, and bidirectional typing. In proof theory, the technique of focusing [Andreoli 1992] exploits invertibility properties of logical formulas (types), as they appear in inference rules (typing rules), to rule out many redundant proofs. Having fewer possible proofs makes proof search more tractable. Brock-Nannestad et al. [2015] and Espírito Santo [2017] study the relation between CBPV and focusing: Each work provides a focused calculus that is essentially the same as CBPV, “up to the question of \(\eta\) -expansion” [Brock-Nannestad et al. 2015]. Our system is also a focused variant of CBPV; in fact, it arises from a certain focalization (and bidirectionalization) of ordinary intuitionistic logic.

An inference rule is invertible if its conclusion implies its premises. For example, in intuitionistic logic, the right rule for implication is invertible because its premise \(\Gamma , A {\vdash} B\) can be derived from its conclusion \(\Gamma {\vdash} A \rightarrow B\) :

However, both right rules for disjunction, for example, are not invertible, which we can prove with a counterexample: \(A_1 + A_2 {\vdash} A_1 + A_2\) but \(A_1 + A_2 \nvdash A_1\) and \(A_1 + A_2 \nvdash A_2\) . In a sequent calculus, positive formulas have invertible left rules and negative formulas have invertible right rules. A weakly focused sequent calculus eagerly applies non-invertible rules as far as possible (in either left- or right-focusing stages); a strongly focused sequent calculus does, too, but also eagerly applies invertible rules as far as possible (in either left- or right-inversion stages). There are also stable stages (or moments) in which a decision has to be made between focusing on the left or on the right [Espírito Santo 2017]. The decision can be made explicitly via proof terms (specifically, cuts): In our system, a principal task of let-binding, a kind of cut, is to focus on the left (to process the list of arguments in a bound function application); and a principal task of pattern matching, another kind of cut, is to focus on the right (to decompose the value being matched against a pattern).

From a Curry–Howard view, let-binding and pattern matching are different kinds of cuts. The cut formula A—basically, the type being matched or let-bound—must be synthesized (inferred) as an output (judgmentally, \(\cdots {\color{red}{\Rightarrow}} A\) ) from heads h (variables and annotated values) or bound expressions g (function application and annotated returner expressions); and ultimately, the outcomes of these cuts in our system are synthesized. But all other program terms are checked against input types A: judgmentally, \(\cdots {\color{blue}{\Leftarrow}} A \cdots\) or \(\cdots [A] {\vdash} \cdots\) . In this sense, both our declarative and algorithmic type systems are bidirectional [Dunfield and Krishnaswami 2021].

In inversion stages, that is, expression typechecking (where a negative type is on the right of a turnstile) and pattern matching (where a positive type is on the left of a turnstile), refinements often need to be extracted from types to be used. For example, suppose we want to check the expression \({\lambda} {x}. {\tt return}\,{x}\) against the type \((1 \wedge \mathsf {ff}) \rightarrow {\uparrow \!{(1 \wedge \mathsf {ff})}}\) , which is semantically equivalent to \(\mathsf {ff}\mathrel {\supset }1 \rightarrow {\uparrow \!{(1 \wedge \mathsf {ff})}}\) . We need to extract \(\mathsf {ff}\) (of \((1 \wedge \mathsf {ff}) \rightarrow \cdots\) ) and put it in the logical context so we can later use it (in typechecking the value x) to verify \(\mathsf {ff}\) (of \(\cdots {\uparrow \!{(1 \wedge \mathsf {ff})}}\) ). If we instead put \(x : 1 \wedge \mathsf {ff}\) in the program context, then \(\mathsf {ff}\) would not be usable (unless we can extract it from the program context, but its simpler to extract from types as soon as possible rather than to extend the extraction judgment or to add another one) and typechecking would fail (it should succeed). Similarly, since subtyping may be viewed as implication, index information from positive subtypes or negative supertypes needs to be extracted for use. Declaratively, it is okay not to extract eagerly at polarity shifts in subtyping (the subtyping rules that extract are invertible), but it seems necessary in the algorithmic system.

Our declarative system includes two focusing stages, one (value typechecking) for positive types on the right of the turnstile ( \({\vdash}\) ) and the other (spine typing) for negative types on the left. Our algorithmic system closely mirrors the declarative one, but does not conjure index instantiations or witnesses (like t in DeclSpine \(\forall\) below), and instead systematically introduces and solves existential variables (like solving the existential variable \(\hat{a}\) as t in AlgSpine \(\forall\) below), which we keep in algorithmic contexts \(\Delta\) .

For example, applying a function of type \(\forall {b:\mathbb {N}}.\: \mathsf {List}{{(\mathsf {Nat})}}{{(b)}} \rightarrow \cdots\) to the list \([4,1,2]\) should solve b to an index semantically equal to 3; the declarative system guesses an index term (like \(3+0\) ), but the algorithmic system mechanically solves for it.

Our algorithmic right-focusing judgment has the form \({\Theta ; \Delta }; {\Gamma } {\vdash} {v} {\color{blue}{\Leftarrow}} {P} \mathrel {/}{\chi } \dashv {\Delta ^{\prime }}\) , where \(\chi\) is an output list of typing constraints and \(\Delta ^{\prime }\) is an output context that includes index solutions to existentials. Similarly, the left-focusing stage is \({\Theta ; \Delta }; {\Gamma }; [{N}] {\vdash} {s} \gg {{\uparrow \!{P}}} \mathrel {/}{\chi } \dashv {\Delta ^{\prime }}\) ; it focuses on decomposing N (the type of the function being applied), introducing its existential variables for the arguments in the list s (sometimes called a spine [Cervesato and Pfenning 2003]) and outputting its guards to verify at the end of decomposition (an upshift). These existential variables flow to the right-focusing stage (value typechecking) and are solved there, possibly via subtyping. Constraints \(\chi\) are only checked right at the end of focusing stages, when all their existential variables are solved. For example, consider our rule for (fully) applying a function h to a list of arguments s:

After synthesizing a thunk type \({\downarrow \!{N}}\) for the function h we are applying, we process the entire list of arguments s, until N’s return type \({\uparrow \!{P}}\) . All (existential) value-determined indexes \(\Xi _N\) of N are guaranteed to be solved by the time an upshift is reached, and these solutions are eagerly applied to constraints \(\chi\) , so \(\chi\) does not have existential variables and is hence SMT-solvable ( \({\Theta }; {\Gamma } \lhd {\chi }\) ). The polarization of CBPV helps guarantee all solutions have no existential variables. Focusing stages introduce existential variables to input types, which may appear initially as a positive supertype in the subtyping premise for typechecking (value) variables. These existential variables are solved using the positive subtype, which never has existential variables. Dually, negative subtypes may have existential variables, but negative supertypes never do.

Our system requires intermediate computations like \(h(s)\) to be explicitly named and sequenced by let-binding (a kind of A-normal [Flanagan et al. 1993] or let-normal form). Combined with focusing, this allows us to use (within the value typechecking stage) subtyping only in the typing rule for (value) variables. This makes our subsumption rule syntax-directed, simplifying and increasing the efficiency of our algorithm. We nonetheless prove a general subsumption lemma, which is needed to prove that substitution respects typing, a key syntactic or operational correctness property.

Focusing also gives us pattern matching for free [Krishnaswami 2009]: From a Curry–Howard view, the left-inversion stage is pattern matching. The (algorithmic³) left-inversion stage in our system is written \({\Theta }; {\Gamma }; [{P}] \rhd {\lbrace {{r}_{i}} \mathbin {\Rightarrow }{{e}_{i}}\rbrace _{{i} \in {I}}} {\color{blue}{\Leftarrow}} {N}\) : It decomposes the positive P (representing the pattern being matched) to the left of the turnstile (written \(\rhd\) to distinguish the algorithmic judgment from the corresponding declarative judgment, which instead uses \({\vdash}\) ). Our system is “half” strongly focused: We eagerly apply right-invertible but not left-invertible rules. This makes pattern matching in our system resemble the original presentation of pattern matching in CBPV. From a Curry–Howard view, increasing the strength of focusing would permit nested patterns.

A pattern type can have index equality constraints, such as for refined ADT constructors (for example, that the length of an empty list is zero) as output by unrolling. By using these equality constraints, we get a coverage-checking algorithm. For example, consider checking get (introduced in Section 1) against the type

At the clause

we extract a logically inconsistent context ( \(l:\mathbb {N}, k:\mathbb {N}, l = 0, k \lt l\) ), which entails that unreachable checks against any type. Proof-theoretically, this use of equality resembles the elimination rule for Girard–Schroeder-Heister equality [Girard 1992; Schroeder-Heister 1994].

Bidirectional typing controls the flow of type information. Focusing in our system directs the flow of index information. The management of the flow of type refinement information, via the stratification of both focusing and bidirectionality, makes our algorithmic metatheory highly manageable.

We show how to verify a non-structurally recursive mergesort function in our system: namely, that it terminates and returns a list with the same length as the input list (to verify it returns an ordered list, we need to extend our system with multi-argument measures, which is outside the scope of this article). We only consider sorting lists of natural numbers \(\mathsf {Nat}\) , defined as \(\exists {n : \mathbb {N}}.\: \mathsf {Nat}({n})\) . For clarity, and continuity with Sections 1 and 2, we sometimes use syntactic sugar such as clausal pattern-matching, combining let-binding with pattern-matching on the let-bound variable, using “if-then-else” rather than pattern-matching on Boolean type, and combining two or more pattern-matching expressions into one with a nested pattern such as \(x :: y :: \mathit {xs}\) .

Given type A and \(n : \mathbb {N}\) , we define \(\mathsf {List}{{(A)}}{{(n)}}\) by \({\left\lbrace {\nu : \textsf {List} \; A} \;\middle |\; {\textsf {len} \; \nu = n}\right\rbrace }\) . Modulo a small difference (see Section 4.6), our unrolling judgment unrolls \(\textsf {List}(A)(n)\) to

which is a refinement of \(1 + (| A | \times \mathsf {List} \; | A |)\) . This is an unrolling of the inductive type, not the inductive type itself, so we must roll values of it into the inductive type. We use syntactic sugar: namely, \([]\) stands for \({\tt into}({{\tt inj}_{1}\, \texttt{ ()}})\) and \(x :: \mathit {xs}\) stands for \({\tt into}({{\tt inj}_{2}\, \langle {x}, {\mathit {xs}}\rangle })\) .

Just as we need a natural number type associating natural number program values with natural number indexes, we need a Boolean type of values corresponding to Boolean indexes. To this end, define the measure

Given \(b:\mathbb {B}\) , the singleton type of Boolean b is \(\mathsf {Bool}(b) = {\left\lbrace {\nu : \mathsf {Bool}} \;\middle |\; {\mathsf {ixbool} \; \nu = b}\right\rbrace }\) . Our unrolling judgment (Section 4.6) outputs the following type, a refinement of the Boolean type encoded as \(1 + 1\) :

We encode \({\tt true}\) as \({\tt into}({{\tt inj}_{1}\,{\texttt{ ()}}})\) , which has type \(\mathsf {Bool}(\mathsf {tt})\) , and \({\tt false}\) as \({\tt into}({{\tt inj}_{2}\,{\texttt{ ()}}})\) , which has type \(\mathsf {Bool}(\mathsf {ff})\) . The Boolean type \(\mathsf {Bool}\) is defined as \(\exists {b:\mathbb {B}}.\: \mathsf {Bool}(b)\) .

Assume we have the following:

The SMT solver Z3 [de Moura and Bjørner 2008], for example, supports integer division (and modulo and remainder operators); internally, these operations are translated to multiplication. Here, we are considering natural number indexes, but we can add the constraint \(n \ge 0\) (for naturals n) when translating them to integers in an SMT solver such as Z3. Allowing integer division in general is not SMT decidable, but for this example, n is always instantiated to a constant (2), which is decidable. Note that Z3 supports division by zero, but our \(\mathsf {div}\) has a guard requiring the divisor to be nonzero ( \(n \ne 0\) ), so we need not consider this. Division on naturals takes the floor of what would otherwise be a rational number (for example, \(3 \div 2 = 1\) ).

First, we define the function \(\mathsf {merge}\) for merging two lists while preserving order. It takes two lists as inputs, but also a natural number representing the sum of their lengths. Since at least one list decreases in length at recursive calls, so does the sum of their lengths, implying the function terminates when applied. However, in the refined system presented in (the figures of) this article, to keep things simple, we provide only one rule for recursive expressions, whose termination metric is \(\lt\) on natural numbers. Because the system as presented lacks a rule that supports a termination metric on sums \(n_1 + n_2\) of natural numbers, we need to reify the sum \(n = n_1 + n_2\) of the length indexes \(n_1\) and \(n_2\) into a ghost parameter n of (asserting) singleton type. However, we emphasize the ghost parameter in this example is not a fundamental limitation of our system, because our system can be extended to include other termination metrics such as \(\lt\) on the sum of natural numbers (we discuss this further in Section 4.7).

In a well-typed let-binding \({\tt let}\;{x}\,\texttt {=}\,{g}{\tt ;}\; e\) the bound expression g is a value-returning computation (that is, has upshift type), and e is a computation that binds to x the value (of positive type) resulting from computing g. (Liquid Haskell, lacking CBPV’s type distinction between computations and values, instead approximates whether binders terminate to a value.) Since x has positive type, we can match it against patterns (see, for example, the final clause of \(\mathsf {split}\) , discussed next).

We now define the function \(\mathsf {split}\) that takes a list and splits it into two lists. It is a standard “every-other” implementation, and we have to be a bit careful about the type refinement so as not to be “off by one” in the lengths of the resulting lists.

We are ready to implement \(\mathsf {mergesort}\) , but, since we use a ghost parameter, we need to define an auxiliary function \(\mathsf {auxmergesort}\) additionally taking the length of the list being ordered. We introduce syntactic sugar for a let-binding followed by pattern-matching on its result.

Finally, we define a \(\mathsf {mergesort}\) that is verified to terminate and to return a list of the same length as the input list.

In the system of this article, we cannot verify that \(\mathsf {mergesort}\) returns a sorted list. This is because our system lacks multi-argument measures that can specify relations between indexes of different parts of a data type. (To handle this, we are extending our system with multi-argument measures, which is nontrivial and requires a significant degree of additional machinery outside the scope of this article.) But this example is interesting nonetheless, because \(\mathsf {auxmergesort}\) is not structurally recursive: Its recursive calls are on lists obtained by splitting the input list roughly in half, not on the structure of the list ( \(- :: -\) ). Further, it showcases the main features of our foundational system, the declarative specification of which we turn to next, in Section 4.

We present our core declarative calculus and type system.

First, we discuss the syntax of program terms, types, index terms, sorts, functors, algebras, and contexts. Then, in Section 4.1, we discuss the index sorting judgment \(\Theta {\vdash} t : \tau\) and the propositional validity judgment \({\Theta } {\vdash} {\phi } \;\mathsf {true}\) , index-level substitution, and basic logical properties required of the index domain. In Section 4.2, we discuss the well-formedness of (logical and program) contexts ( \({\Theta }\; \mathsf {ctx}\) and \({\Theta } {\vdash} {\Gamma }\; \mathsf {ctx}\) ), types ( \({\Theta } {\vdash} {A}\; \mathsf {type} {[{\Xi }}]\) ), functors ( \({\Theta } {\vdash} {\mathcal {F}}\; \mathsf {functor} {[{\Xi }]}\) ), and algebras ( \({\Xi }; {\Theta } {\vdash} {\alpha } : {F}({\tau }) \Rightarrow {\tau }\) ). In Section 4.3, we discuss judgmental equivalence. In Section 4.4, we discuss extraction ( \({\Theta }\vdash{A}\rightsquigarrow{A^{\prime }}[{\Theta ^{\prime }}]\) ). In Section 4.5, we discuss subtyping ( \({\Theta }\vdash {A}\leq{B}\) ). In Section 4.6, we discuss the unrolling judgment for refined inductive types. In Section 4.7, we discuss the typing system. In Section 4.8, we extend substitution to that of program values for program variables and prove a substitution lemma stating that typing is stable under substitution (a key operational correctness result).

In Figure 1, we summarize the key judgments constituting the declarative system. In the figure, “pre.” abbreviates “presupposes,” which basically lists the judgments (rightmost column) we tend to leave implicit in rules defining the given judgment (leftmost column). Presuppositions also indicate the (input or output) moding of judgments. For example, on the one hand, \({\Theta }; {\Gamma } {\vdash} {v} {\color{blue}{\Leftarrow}} {P}\) presupposes \({\Theta } {\vdash} {\Gamma }\; \mathsf {ctx}\) and \({\Theta } {\vdash} {P}\; \mathsf {type} {[{\Xi _P}}]\) for some \(\Xi _P\) , where the former presupposes \({\Theta }\; \mathsf {ctx}\) , and \(\Theta\) , \(\Gamma\) , and P are input-moded; on the other hand, \({\Theta }; {\Gamma } {\vdash} {h} {\color{red}{\Rightarrow}} {P}\) does not presuppose \({\Theta } {\vdash} {P}\; \mathsf {type} {[{\Xi _P}}]\) for some \(\Xi _P\) , but rather, we must prove that the output-moded P is well-formed (which is straightforward). Groups of mutually defined judgments are separated by blank lines.

Program terms. Program terms are defined in Figure 2. We polarize terms into two main syntactic categories: expressions (which have negative type) and values (which have positive type). Program terms are further distinguished according to whether their principal types are synthesized (heads and bound expressions) or checked (spines and patterns).

Expressions e consist of functions \({\lambda} {x}{e}\) , recursive expressions \({\tt rec}\;{x:N}.\;{e}\) , let-bindings \({\tt let}\;{x}\,\texttt {=}\,{g}{\tt ;}\;{e}\) , match expressions \({\tt match}\;{h}\;{\lbrace {{r}_{i}} \mathbin {\Rightarrow }{{e}_{i}}\rbrace _{{i} \in {I}}}\) , value returners (or producers) \({\tt return}\,{v}\) , and an unreachable expression unreachable (such as an impossible match). Bound expressions g, which can be let-bound, consist of expressions annotated with a returner type \(\texttt {(}{e} : {{\uparrow \!{P}}}\texttt {)}\) and applications \(h(s)\) of a head h to a spine s. Heads h, which can be applied to a spine or pattern-matched, consist of variables x and positive-type-annotated values \(\texttt {(}{v} : {P}\texttt {)}\) . Spines s are lists of values; we often omit the empty spine \(\cdot\) , writing (for example) \(v_1, v_2\) instead of \(v_1, v_2, \cdot\) . In match expressions, heads are matched against patterns r.

Values consist of variables x, the unit value \(\left\langle \right\rangle\) , pairs \(\langle {v_1}, {v_2}\rangle\) , injections into sum type \({\tt inj}_{k}\,{v}\) where k is 1 or 2, rollings into inductive type \({\tt into}({v})\) , and thunks (suspended computations) \(\left\lbrace {e}\right\rbrace\) .

Types. Types are defined in Figure 3. Types are polarized into positive (value) types P and negative (computation) types N. We write A, B, and C for types of either polarity.

Positive types consist of the unit type 1, products \(P_1 \times P_2\) , the void type 0, sums \(P_1 + P_2\) , downshifts (of negative types; thunk types) \({\downarrow \!{N}}\) , asserting types \(P \wedge \phi\) (read “P with \(\phi\) ”), index-level existential quantifications \(\exists {a:\tau }.\: P\) , and refined inductive types \({\left\lbrace {\nu : \mu F} \;\middle |\; {(\mathsf {fold}_{F}\;{\alpha })\,{\nu } =_\tau t}\right\rbrace }\) . We read \({\left\lbrace {\nu : \mu F} \;\middle |\; {(\mathsf {fold}_{F}\;{\alpha })\,{\nu } =_\tau t}\right\rbrace }\) as the type having values \(\nu\) of inductive type \(\mu F\) (with signature F) such that the (index-level) measurement \((\mathsf {fold}_{F}\;{\alpha })\,{\nu } =_\tau t\) holds; in Sections 4.0.1 and 5, we explain the metavariables F, \(\alpha\) , \(\tau\) , and t, as well as what these and the syntactic parts \(\mu\) and \(\mathsf {fold}\) denote. Briefly, \(\mu\) roughly denotes “least fixed point of” and a \(\mathsf {fold}\) over F with \(\alpha\) (having carrier sort \(\tau\) ) indicates a measure on the inductive type \(\mu F\) into \(\tau\) .

Negative types consist of function types \(P \rightarrow N\) , upshifts (of positive types; lift or returning types) \({\uparrow \!{P}}\) (dual to \({\downarrow \!{N}}\) ), propositionally guarded types \(\phi \mathrel {\supset }N\) (read “ \(\phi\) implies N”; dual to \(P \wedge \phi\) ), and index-level universal quantifications \(\forall {a:\tau }.\: N\) (dual to \(\exists {a:\tau }.\: P\) ).

In \(P \wedge \phi\) and \(\phi \mathrel {\supset }N\) , the index proposition \(\phi\) has no runtime content. Neither does the a in \(\exists {a:\tau }.\: P\) and \(\forall {a:\tau }.\: N\) , nor the recursive refinement predicate \((\mathsf {fold}_{F}\;{\alpha })\,{\nu } =_\tau t\) in \({\left\lbrace {\nu : \mu F} \;\middle |\; {(\mathsf {fold}_{F}\;{\alpha })\,{\nu } =_\tau t}\right\rbrace }\) .

Index language: sorts, terms, and propositions. Our type system is parametric in the index domain, provided the latter has certain (basic) properties. For our system to be decidable, the index domain must be decidable. It is instructive to work with a specific index domain: Figure 4 defines a quantifier-free logic of linear equality, inequality, and arithmetic, which is decidable [Barrett et al. 2009].

Sorts \(\tau\) consist of Booleans \(\mathbb {B}\) , natural numbers \(\mathbb {N}\) , integers \(\mathbb {Z}\) , and products \(\tau _1 \times \tau _2\) . Index terms t consist of variables a, numeric constants n, addition \(t_1 + t_2\) , subtraction \(t_1 - t_2\) , pairs \((t_1, t_2)\) , projections \(\pi _1\,{t}\) and \(\pi _2\,{t}\) , and propositions \(\phi\) . Propositions \(\phi\) (the logic of the index domain) are built over index terms and consist of equality \(t_1 = t_2\) , inequality \(t_1 \le t_2\) , conjunction \(\phi _1 \wedge \phi _2\) , disjunction \(\phi _1 \vee \phi _2\) , negation \(\lnot \phi\) , trivial truth \(\mathsf {tt}\) , and trivial falsity \(\mathsf {ff}\) .

We prove type (and substitution) soundness of the declarative system with respect to an elementary domain-theoretic denotational semantics. Refined type soundness implies the refined system’s totality and logical consistency.

Refinement type systems refine already-given type systems, and the soundness of the former depends on that of the latter [Melliès and Zeilberger 2015]. Thus, the semantics of our refined system is defined in terms of that of its underlying, unrefined system, which we discuss in Section 5.1.

Notation: We define the disjoint union \(X \uplus Y\) of sets X and Y by \(X \uplus Y = (\lbrace 1\rbrace \times X) \cup (\lbrace 2\rbrace \times Y)\) and define \({\mathit {inj}}_{k} : X_k \rightarrow X_1 \uplus X_2\) by \({\mathit {inj}}_{k}(d) = (k, d)\) . Semantic values are usually named d, f, g, or V.

We design our algorithmic system in the spirit of those of Dunfield and Krishnaswami [2013];, 2019], but those systems do not delay constraint verification until all existentials are solved. The algorithmic rules closely mirror the declarative rules, except for a few key differences:

Syntactically, objects in the algorithmic system are not much different from corresponding objects of the declarative system. We extend the grammar for index terms with a production of existential variables, which we write as an index variable with a hat \(\hat{a}\) , \(\hat{b}\) , or \(\hat{c}\) :

We use this (algorithmic) index grammar everywhere in the algorithmic system, using the same declarative metavariables. However, we write algorithmic logical contexts with a hat: \(\hat{\Theta }\) . Algorithmic logical contexts \(\hat{\Theta }\) only appear in output mode and are like (input) logical contexts \(\Theta\) , but propositions listed in them may have existential variables (its index variable sortings \(a:\tau\) are universal).

Constraints are added to the algorithmic system. Figure 14 gives grammars for subtyping and typing constraints. In contrast to DML, the grammar does not include existential constraints.

Checking constraints boils down to checking propositional validity, \({\Theta } {\vdash} {\phi } \;\mathsf {true}\) , which is analogous to checking verification conditions in the tradition of imperative program verification initiated by Floyd [1967] and Hoare [1969] (where programs annotated with Floyd–Hoare assertions are analyzed, generating verification conditions whose validity implies program correctness). These propositional validity constraints are the constraints that can be automatically verified by a theorem prover such as an SMT solver. The (algorithmic) W constraint verification judgment is written \({\Theta } \models {W}\) and means that W algorithmically holds under \(\Theta\) . Notice that the only context in the judgment is \(\Theta\) , which has no existential variables; this reflects the fact that we delay verifying W until W has no existential variables (in which case, we say W is ground). Similarly, \({\Theta }; {\Gamma } \lhd {\chi }\) is the (algorithmic) \(\chi\) verification judgment, meaning all of the constraints in \(\chi\) algorithmically hold under \(\Theta\) and \(\Gamma\) , and here \(\chi\) is also ground (by focusing).

We prove that the algorithmic system (Section 6) is decidable, as well as sound and complete with respect to the declarative system (Section 4).

Typing refinement. As far as we know, Constable [1983] was first to introduce the concept of refinement types (though not by that name) as logical subsets of types, writing {x:A|B} for the subset type classifying terms x of type A that satisfy proposition B. Freeman and Pfenning [1991] introduced type refinement to the programming language ML via datasort refinements—inclusion hierarchies of ML-style (algebraic, inductive) datatypes—and intersection types for Standard ML: They showed that full type inference is decidable under a refinement restriction and provided an algorithm based on abstract interpretation. The dangerous interaction of datasort refinements, intersection types, side effects, and call-by-value evaluation was first dealt with by Davies and Pfenning [2000] by way of a value restriction on intersection introduction; they also presented a bidirectional typing algorithm.

Dependent ML (DML) [Xi 1998; Xi and Pfenning 1999] extended the ML type discipline parametrically by index domains. DML is only decidable modulo decidability of index constraint satisfiability. DML uses a bidirectional type system with index refinements for a variant of ML, capable of checking properties ranging from in-bound array access [Xi and Pfenning 1998] to program termination [Xi 2002]. DML, similarly to our system, collects constraints from the program and passes them to a constraint solver, but does not guarantee that they are SMT solvable (unlike our system). This is also the approach of systems like Stardust [Dunfield 2007a] (which combines datasort and index refinement and supports index refinements that are not value-determined, that is, invaluable refinements, which we do not consider) and those with liquid types [Rondon et al. 2008]. The latter are based on a Hindley–Milner approach; typically, Hindley–Damas–Milner inference algorithms [Hindley 1969; Milner 1978; Damas and Milner 1982] generate typing constraints to be verified [Heeren et al. 2002].

Due to issues with existential index instantiation, the approach of Xi [1998] (incompletely) translated programs into a let-normal form [Sabry and Felleisen 1993] before typing them, and Dunfield [2007b] provided a complete let-normal translation for similar issues. The system in this paper is already let-normal.

Liquid types. Rondon et al. [2008] introduced logically qualified data types, that is, liquid types, in a system that extends Hindley–Milner to infer (by abstract interpretation) refinements based on built-in or programmer-provided refinement templates or qualifiers. Kawaguchi et al. [2009] introduced recursive refinement via sound and terminating measures on algebraic data types; they also introduced polymorphic refinement. Vazou et al. [2013] generalize recursive and polymorphic refinement into a single, more expressive mechanism: abstract refinement. Our system lacks polymorphism, which we plan to study in future work. Abstract refinements go together with multi-argument measures, because abstract refinements may be thought of as predicates of higher-order sort, and we can encode multi-argument measures using higher-order sorts. Extending our system with higher-order sorts and abstract refinements is ongoing work. In future work, it would be interesting to study other features of liquid typing in our setting. Extending our system with liquid inference of refinements, for example, would require adding Hindley–Milner type inference that creates templates, as well as mechanisms to solve these templates, possibly in an initial phase using abstract interpretation.

Unlike DML (and our system), liquid type systems do not distinguish index terms from programs. While this provides simplicity and convenience to the user (from their perspective, there is just one language), it makes it relatively difficult to provide liquid type systems a denotational semantics and to prove soundness results denotationally (rather than operationally), in contrast to our system (we should be able to recover some of this convenience, by requiring users, for example, to make measure annotations like Liquid Haskell). It creates other subtleties such as the fact that annotations for termination metrics in Liquid Haskell must be internally translated to ghost parameters similar to that used in Section 3. By contrast, if we extend our system with additional termination metrics, because these metrics are at the index level, then we can obviate such ghost parameters. Liquid types’ lack of index distinction also makes it trickier to support computational effects and evaluation orders.

Initial work on liquid types [Rondon et al. 2008; Kawaguchi et al. 2009] used call-by-value languages, but Haskell uses lazy evaluation, so Liquid Haskell was discovered to be unsound [Vazou et al. 2014]. Vazou et al. [2014] regained type soundness by imposing operational-semantic restrictions on subtyping and let-binding. In their algorithmic subtyping, there is exactly one rule, \(\preceq\) -Base-D, which pertains to refinements of base types (integers, Booleans, and so on) and inductive data types; however, these types have a well-formedness restriction, namely, that the refinement predicates have the type of Boolean expressions that reduce to finite values. But this restriction alone does not suffice for soundness under laziness and divergence. As such, their algorithmic typing rule T-Case-D, which combines let-binding and pattern matching, uses an operational semantics to approximate whether or not the bound expression terminates. If the bound expression might diverge, then so might the entire case expression; otherwise, it checks each branch in a context that assumes the expression reduces to a (potentially infinite Haskell) value.

We also have a type well-formedness restriction, but it is purely syntactic, and only on index quantification, requiring them to be associated with a fold that is necessarily decidable by virtue of a systematic phase distinction between the index level and the program level. Further, via type polarization, our let-binding rule requires the bound expression to return a value, we only allow value types in our program contexts, and we cannot extract index information across polarity shifts (such as in a suspended computation). Therefore, in our system, there is no need to stratify our types according to an approximate criterion; rather, we exploit the systemic distinction between positive (value) types and negative (computation) types, which Levy [2004] designed or discovered to be semantically well-behaved. We suspect that liquid types’ divergence-based stratification is indirectly grappling with logical polarity. Because divergence-based stratification is peculiar to the specific effect of nontermination, it is unclear how their approach may extend to other effects. By way of a standard embedding of CBN or CBV into (our focalized variant of) CBPV, we can obtain CBN or CBV subtyping and typing relations automatically respecting any necessary value or covalue restrictions [Zeilberger 2009]. Further, our system is already in a good position to handle the addition of effects other than nontermination.

Contract calculi. Software contracts express program properties in the same language as the programs themselves; Findler and Felleisen [2002] introduced contracts for runtime verification of higher-order functional programs. These latent contracts are not types, but manifest contracts are [Greenberg et al. 2010]. Manifest contracts are akin to refinement types. Indeed, Vazou et al. [2013] sketch a proof of type soundness for a liquid type system by translation from liquid types to the manifest contract calculus F_H of Belo et al. [2011]. However, there is no explicit translation back, from F_H to liquid typing. They mention that the translated terms in F_H do not have upcasts because the latter in F_H are logically related to identity functions if they correspond to static subtyping (as they do in the liquid type system): an upcast lemma. Presumably, this facilitates a translation from F_H back to liquid types. However, there are technical problems in F_H that break type soundness and the logical consistency of the F_H contract system; Sekiyama et al. [2017] fix these issues, resulting in the system \(\text{F}^{\hspace{1.0pt}\sigma }_{\text{H}}\) , but do not consider subtyping and subsumption and do not prove an upcast lemma.

Bidirectional typing. Bidirectional typing [Pierce and Turner 2000] is a popular way to implement a wide variety of systems, including dependent types [Coquand 1996; Abel et al. 2008], contextual types [Pientka 2008], and object-oriented languages [Odersky et al. 2001]. The bidirectional system of Peyton Jones et al. [2007] supports higher-rank polymorphism. Dunfield and Krishnaswami [2013] also present a bidirectional type system for higher-rank polymorphism, but framed more proof theoretically; Dunfield and Krishnaswami [2019] extend it to a richer language with existentials, indexed types, sums, products, equations over type variables, pattern matching, polarized subtyping, and principality tracking. The bidirectional system of this paper uses logical techniques similar to the systems of Dunfield and Krishnaswami, but it does not consider polymorphism. A survey paper [Dunfield and Krishnaswami 2021] includes some discussion of bidirectional typing’s connections to proof theory. Basically, good bidirectional systems tend to distinguish checking and synthesizing terms or proofs according to their form, such as normal or neutral.

Proof theory, polarization, focusing, and analyticity. The concept of polarity most prominent in this article dates back to Andreoli’s work on focusing for tractable proof search [Andreoli 1992] and Girard’s work on unifying classical, intuitionistic, and linear logic [Girard 1993]. Logical polarity and focusing have been used to explain many common phenomena in programming languages. We mentioned in the overview that Zeilberger [2009] explains the value and evaluation context restrictions in terms of focusing; and Krishnaswami [2009] explains pattern matching as (proof terms of) the left-inversion stage of focused systems (also, that system is bidirectional). More broadly, Downen [2017] discusses many logical dualities common in programming languages.

Brock-Nannestad et al. [2015] study the relation between polarized intuitionistic logic and CBPV. They obtain a bidirectionally typed system of natural deduction related to a variant of the focused sequent calculus LJF [Liang and Miller 2009] by \(\eta\) -expansion (for inversion stages). Espírito Santo [2017] does a similar study, but starts with a focused sequent calculus for intuitionistic logic much like the system of Simmons [2014] (but without positive products), proves it equivalent to a natural deduction system (we think the lack of positive products helps establish this equivalence), and defines, also via \(\eta\) -expansion, a variant of CBPV in terms of the natural deduction system. Our system is not in the style of natural deduction, but rather sequent calculus. We think our system relates to CBPV in a similar way—via \(\eta\) -expansion—but we do not prove it in this article, because we focus on proving type soundness and algorithmic decidability, soundness, and completeness.

Barendregt et al. [1983] discovered that a program that typechecks (in a system with intersection types) using subtyping can also be checked without using subtyping, if the program is sufficiently \(\eta\) -expanded. An analogous phenomenon involving identity coercion was studied by Zeilberger [2009] in a focused setting. Similarly, our ability to place subtyping solely in (value) variable typechecking is achievable due to the focusing (and let-normality) of our system.

Interpreting Kant, Martin-Löf [1994] considers an analytic judgment to be one that is derivable using information found only in its inputs (in the sense of the bidirectional modes, input and output). A synthetic judgment, in contrast, requires us to look beyond the inputs of the judgment to find a derivation. The metatheoretic results for our algorithmic system demonstrate that our judgments are analytic, except the judgment \({\Theta } {\vdash} {\phi } \;\mathsf {true}\) , which is verified by an external SMT solver. As such, our system may be said to be analytic modulo an external SMT solver. Focusing, in proper combination with bidirectional typing (which clarifies where to put type annotations), let-normality and value-determinedness, guarantees that all information needed to generate verification conditions suitable for an SMT solver may be found in the inputs to judgments. In our system, cut formulas can always be inferred from a type annotation or by looking up a variable in the program context, making all our cuts analytic in the sense of Smullyan [1969].

Dependent types. Dependent types, introduced by Martin-Löf [1971];, 1975], are a key conceptual and historical precursor to index refinement types. Dependent types may depend on arbitrary program terms, not only terms restricted to indexes. This is highly expressive, but undecidable in languages with divergence. The main difference between refinement and dependent typing is that refinement typing attempts to increase the expressivity of a highly automatic type system, whereas dependent typing attempts to increase the automation of a highly expressive type system. Semantically, refinement type systems differ from dependent type systems in that they refine a pre-existing type system, so erasure of refinements always preserves typing.

Many dependent type systems impose their own restrictions for the sake of decidability. In Cayenne [Augustsson 1998], typing can only proceed a given number of steps. All well-typed programs in Epigram [McBride and McKinna 2004] are required to terminate so its type equivalence is decidable. Epigram, and other systems [Chen and Xi 2005; Licata and Harper 2005], allow programmers to write explicit proofs of type equivalence.

Systems such as ATS [Xi 2004] and \(\text{F}^\star\) [Swamy et al. 2016] can be thought of as combining refinement and dependent types. These systems aim to bring the best of both refinement and dependent types, but ATS is more geared to practical, effectful functional programming (hence, refinement types), while \(\text{F}^\star\) is more geared to formal verification and dependent types. Unlike our system, they allow the programmer to provide proofs. The overall design of ATS is closer to our system than that of \(\text{F}^\star\) , due to its phase distinction between statics and dynamics; but it allows the programmer to write (in the language itself) proofs to simplify or eliminate constraints for the (external) constraint solver: Xi calls this internalized constraint solving. It should be possible to internalize constraint solving to some extent in our system. Liquid Haskell has a similar mechanism called refinement reflection [Vazou et al. 2017] in which programmers can write manual proofs (in Haskell) in cases where automatic Proof by Logical Evaluation and SMT solving fail.

Both ATS and \(\text{F}^\star\) have a CBV semantics, which is inherently monadic [Moggi 1989b]. Our system is a variant of CBPV, which subsumes both CBV and CBN. These systems consider effects other than divergence, like exceptions, mutable state, and input/output, which we hope to add to our system in future work; this should go relatively smoothly, because CBPV is inherently monadic. The system \(\text{F}^\star\) allows for termination metrics other than strong induction on naturals, such as lexicographic induction, but we think it would be straightforward to add such metrics to our system in the way discussed in Section 4.7.

Data abstraction and category theory. Categorically, inductive types are initial algebras of endofunctors. We only consider certain polynomial endofunctors, which specify tree-shaped or algebraic data structures. Objects (in the sense of object-oriented programming) or coinductive types are dual to inductive types in that, categorically, they are final coalgebras of endofunctors [Cook 2009]. A consideration of categorical duality leads us to a natural (perhaps naïve) question:If we can build a well-behaved system that refines algebraic data types by algebras, could it mean anything to refine objects by coalgebras? We would expect the most direct model of coinductive types would be via negative types, but working out the details is potential future work.

Our rolled refinement types refine type constructors \(\mu F\) . Sekiyama et al. [2015], again in work on manifest contracts, compare this to refining (types of) data constructors and provide a translation from type constructor to data constructor refinements. According to Sekiyama et al. [2015], type constructor refinements (such as our \({\left\lbrace {\nu : \mu F} \;\middle |\; {(\mathsf {fold}_{F}\;{\alpha }) \; \nu =_\tau t}\right\rbrace }\) ) are easier for the programmer to specify, but data constructor refinements (such as the output types of our unrolling judgment) are easier to verify automatically. Sekiyama et al. [2015] say that their translation from type to data constructor refinements is closely related to the work of Atkey et al. [2012] on refining inductive data in (a fibrational interpretation of) dependently typed languages. Atkey et al. [2012] provide “explicit formulas” computing inductive characterizations of type constructor refinements. These semantic formulas resemble our syntactic unrolling judgment, which may be viewed as a translation from type refinements to data constructor refinements.

Ornaments [McBride 2011] describe how inductive types with different logical or ornamental properties can be systematically related using their algebraic and structural commonalities. Practical work in ornaments seems mostly geared toward code reuse [Dagand and McBride 2012], code refactoring [Williams and Rémy 2017], and such. In contrast, this paper focuses on incorporating similar ideas in a foundational index refinement typing algorithm.

Melliès and Zeilberger [2015] provide a categorical theory of type refinement in general, where functors are considered to be type refinement systems. This framework is based on Reynolds’s distinction between intrinsic (or Church) and extrinsic (or Curry) views of typing [Reynolds 1998]. We think that our system fits into this framework, but have not confirmed it formally. This is most readily seen in the fact that the semantics of our refined system is simply the semantics (intrinsic to unrefined typing derivations) of its erasure of indexes, which express extrinsic properties of (erased) programs.

We have presented a declarative system for index-based recursive refinement typing (with nullary measures) that is logically designed, semantically sound, and theoretically implementable. We have proved that our declarative system is sound with respect to an elementary domain-theoretic denotational semantics, which implies that our system is logically consistent and totally correct. We have also presented an algorithmic system and proved it is decidable, as well as sound and complete with respect to the declarative system. Focusing yields CBPV, which already has a clear denotational semantics, and refining it by an index domain (and by measures in it) facilitates a semantics in line with the perspective of Melliès and Zeilberger [2015]. But focusing (in combination with value-determinedness) also allows for an easy proof of the completeness of a decidable typing algorithm. The relative ease with which we demonstrate (denotational-semantic) soundness and (completeness of) decidable typing for a realistic language follows from a single, proof-theoretic technique: focusing.

Researchers of liquid typing have laid out an impressive and extensive research program providing many useful features that would be very interesting to study in our setting. We plan to add parametric polymorphism in future work, which goes along with refinement abstraction [Vazou et al. 2013]. Refinement abstraction may be thought of as predicates of higher-order sort, which can also accommodate multi-argument measures (such as whether a list of naturals is in increasing order). We are adding multi-argument measures and refinement abstraction in ongoing work. It is also of great interest to study other features of liquid typing, such as refinement inference with templates and refinement reflection, though arguably the latter is more closely related to dependent typing.

We also plan to allow the use of multiple measures on inductive types (so we can specify, for example, the type of length-n lists of naturals in increasing order). It would also be interesting to experiment with our value-determinedness technique. By allowing quantification over indexes in propositions whose only variable dependencies are value-determined, we think we can simulate termination metrics by other ones (such as \(\lt\) on sums of natural numbers by \(\lt\) on natural numbers as such).

In future work, we hope to apply our type refinement system (or future extensions of it) to various domains, from static time complexity analysis [Wang et al. 2017] to resource analysis [Handley et al. 2019]. Eventually, we hope to be able to express, for example, that a program terminates within a worst-case amount of time. Our system is parametric in the index domain, provided it satisfies some basic properties. Different index domains may be suitable for different applications. We also hope to add more effects, such as input/output and mutable reference cells. CBPV is built for effects, but our refinement layer may result in interesting interactions between effects and indexes.

Our system may at first seem complicated, but its metatheoretic proofs are largely straightforward, if lengthy (at least as presented). A primary source of this complexity is the proliferation of judgments. However, having various judgments helps us organize different forms of knowledge [Martin-Löf 1996] or (from a Curry–Howard perspective) stages or parts of an implementation (such as pattern-matching, processing an argument list, and so on).

Our system focuses on the feature of nullary measures of algebraic data types and does not include key typing features expected of a realistic programming language (such as additional effects and polymorphism, which we hope to add in future work). Adding such expressive features tends to significantly affect the metatheory and the techniques used to prove it. We hope to reflect on the development of our proofs (including those for systems with polymorphism [Dunfield and Krishnaswami 2013]) in search of abstractions that may help designers of practical, general-purpose functional languages to establish crucial metatheoretic properties.

We thank the anonymous reviewers for their thorough reading and recommendations, which helped to improve our article. We also thank Ondrej Baranovič [2023] for implementing the system presented in this article.