Tridirectional typechecking

In prior work we introduced a pure type assignment system that encompasses a rich set of property types, including intersections, unions, and universally and existentially quantified dependent types. This system was shown sound with respect to a call-by-value operational semantics with effects, yet is inherently undecidable.In this paper we provide a decidable formulation for this system based on bidirectional checking, combining type synthesis and analysis following logical principles. The presence of unions and existential quantification requires the additional ability to visit subterms in evaluation position before the context in which they occur, leading to a tridirectional type system. While soundness with respect to the type assignment system is immediate, completeness requires the novel concept of contextual type annotations, introducing a notion from the study of principal typings into the source program.


INTRODUCTION
Over the last two decades, there has been a steady increase in the use of type systems to capture program properties such as control flow [15], memory management [22], aliasing [20], data structure invariants [11,7,28] and effects [21,14], to mention just a few. Ideally, such type systems specify rigorously, yet at a high level of abstraction, how to reason about a certain class of program properties. This specification usually serves a dual purpose: it is used to relate the properties of interest to the operational semantics of the programming language (for example, proving type preservation), and it is the basis for concrete algorithms for program analysis (for example, via constraint-based type inference).
While the type-based approach has been successful for use in automatic program analysis (for example, for optimization during Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. POPL'04, January [14][15][16]2004, Venice, Italy. Copyright 2004 ACM 1-58113-729-X/04/0001 ...$5.00. compilation), it has been less successful in making the expressive type systems directly available to the programmer. One reason for this is the difficulty of finding the right balance between the brevity of the additional required type declarations and the feasibility of the typechecking problem. Another is the difficulty of giving precise and useful feedback to the programmer on ill-typed programs.
In prior work [9] we developed a system of pure type assignment designed for call-by-value languages with effects and proved progress and type preservation. The intended atomic program properties are data structure refinements [11,10,28], but our approach does not depend essentially on this choice. Atomic properties can be combined into more complex ones through intersections, unions, and universal and existential quantification over index domains. As a pure type assignment system, where terms do not contain any types at all, it is inherently undecidable [4].
In this paper we develop an annotation discipline and typechecking algorithm for our earlier type assignment system. The major contribution is the type system itself which contains several novel ideas, including an extension of the paradigm of bidirectional typechecking to union and existential types, leading to the tridirectional system. While type soundness follows immediately by erasure of annotations, completeness requires that we insert contextual typing annotations reminiscent of principal typings [13,25]. Decidability is not obvious; we prove it by showing that a slightly altered left tridirectional system is decidable (and sound and complete with respect to the tridirectional system).
The basic underlying idea is bidirectional checking [18] of programs containing some type annotations, combining type synthesis with type analysis, first adapted to property types by Davies and Pfenning [7]. Synthesis generates a type for a term from its immediate subterms. Logically, this is appropriate for destructors (or elimination forms) of a type. For example, the first product elimination passes from e : A * B to fst(e) : A. Therefore, if we can generate A * B we can extract A. Dually, analysis verifies that a term has a given type by verifying appropriate types for its immediate subterms. Logically, this is appropriate for constructors (or introduction forms) of a type. For example, to verify that λx. e : A → B we assume x : A and then verify e : B. Bidirectional checking works for both the native types of the underlying programming language and the layer of property types we construct over it.
However, the simple bidirectional model is not sufficient for what we call indefinite property types: unions and existential quantification. This is because the program lacks the prerequisite structure. For example, if we synthesize A ∨ B, the union of A and B, for an expression e, we now need to distinguish the cases: the value of e might have type A or it might have type B. Determining the proper scope of this case distinction depends on how e is used, that is, the position in which e occurs. This means we need a "third di-rection" (whence the name tridirectional): we might need to move to a subexpression, synthesize its type, and only then analyze the expression surrounding it.
Since the tridirectional type system (like the bidirectional one) requires annotations, we want to know that any program well typed in the type assignment system can be annotated so that it is also well typed in the tridirectional system. But with intersection types, such a completeness property does not hold for the usual notion of type annotation (e : A) (as previously noted [16,6,23]), a problem exacerbated by scoping issues arising from quantified types. We therefore extend the notion of type annotation to contextual typing annotation, (e : Γ 1 A 1 , . . . , Γn An), in which the programmer can write several context/type pairs. The idea is that an annotation Γ k A k may be used when e is checked in a context matching Γ k . This idea might also be applicable to arbitrary rank polymorphism, a possibility we plan to explore in future work. Unlike the bidirectional system, the indefinite property types that necessitate the third direction make decidability of typechecking nontrivial. Two ideas come to the rescue. First, to preserve type safety in a call-by-value language with effects, the type of a subterm e can only be brought out if the term containing it has the form E[e] for some evaluation context E, reducing the nondeterminism; this was a key observation in our earlier paper [9]. Second, one never needs to visit a subterm more than once in the same derivation: the system which enforces this is sound and complete.
The remainder of the paper is organized as follows. Section 2 presents a simple bidirectional type system. Section 3 adds refinements and a rich set of types including intersections and unions, using tridirectional rules; this is the simple tridirectional system. In Section 4, we explain our form of typing annotation and prove that the simple tridirectional system is complete with respect to the type assignment system. Section 5 restricts the tridirectional rules and compensates by introducing left rules to yield a left tridirectional system. We prove soundness and completeness with respect to the simple tridirectional system, prove decidability, and use the results in [9] to prove type safety. Finally, we discuss related work (Section 6) and conclude (Section 7).

THE CORE LANGUAGE
In a pure type assignment system, the typing judgment is e : A, where e contains no types (eliding contexts for the moment). In a bidirectional type system, we have two typing judgments: e ↑ A, read e synthesizes A, and e ↓ A, read e checks against A. The most straightforward implementation of such a system consists of two mutually recursive functions: the first, corresponding to e ↑ A, takes the term e and either returns A or fails; the second, corresponding to e ↓ A, takes the term e and a type A and succeeds (returning nothing) or fails. This raises a question: Where do the types in the judgments e ↓ A come from? More generally: what are the design principles behind a bidirectional type system? Avoiding unification or similar techniques associated with full type inference is fundamental to the design of the bidirectional system we propose here. The motivation for this is twofold. First, for highly expressive systems such as the ones under consideration here, full type inference is often undecidable, so we need less automatic and more robust methods. Second, since unification globally propagates type information, it is often difficult to pinpoint the source of type errors.
We think of the process of bidirectional typechecking as a bottomup construction of a typing derivation, either of e ↑ A or e ↓ A. Given that we want to avoid unification and similar techniques, we need each inference rule to be mode correct, terminology borrowed from logic programming. That is, for any rule with conclusion e ↑ A we must be able to determine A from the information in the premises. Conversely, if we have a rule with premise e ↓ A, we must be able to determine A before traversing e.
However, mode correctness by itself is only a consistency requirement, not a design principle. We find such a principle in the realm of logic, and transfer it to our setting. In natural deduction, we distinguish introduction rules and elimination rules. An introduction rule specifies how to infer a proposition from its components; when read bottom-up, it decomposes the proposition. For example, the introduction rule for the conjunction A * B decomposes it to the goals of proving A and B. Therefore, a rule that checks a term against A * B using an introduction rule will be mode correct.
Conversely, an elimination rule specifies how to use the fact that a certain proposition holds; when read top-down, it decomposes a proposition. For example, the two elimination rules for the conjunction A * B decompose it to A and B, respectively. Therefore, a rule that infers a type for a term using an elimination rule will be mode correct.
If we employ this design principle throughout, the constructors (corresponding to the introduction rules) for the elements of a type are checked against a given type, while the destructors (corresponding to the elimination rules) for the elements of a type synthesize their type. This leads to the following rules for functions, in which rule (→I) checks against A → B and rule (→E) synthesizes the type A → B of its subject e 1 .
What do we do when the different judgment directions meet? If we are trying to check e ↓ A then it is sufficient to synthesize a type e ↑ A and check that A = A. More generally, in a system with subtyping, it is sufficient to know that every value of type A also has type A, that is, In the opposite direction, if we want to synthesize a type for e but can only check e against a given type, then we do not have enough information. In the realm of logic, such a step would correspond to a proof that is not in normal form (and might not have the subformula property). The straightforward solution would be to allow source expressions (e : A) via a rule Γ e ↓ A Γ (e : A) ↑ A Unfortunately, this is not general enough due to the presence of intersections and universally and existentially quantified property types. We discuss the issues and our solution in detail in Section 4. For now, only normal terms will typecheck in our system. These correspond exactly to normal proofs in natural deduction. We can therefore already pinpoint where annotations will be required in the full system: exactly where the term is not normal. This will be the case where destructors are applied to constructors (that is, as redexes) and at certain let forms.
In addition we permit datatypes δ with constructors c(e) and corresponding case expressions case e of ms, where the match expressions ms have the form c 1 (x 1 ) ⇒ e 1 | . . . cn (xn) ⇒ en . The constants c are the constructors and case the destructor of elements Types A, B, C :: Terms e ::= x | u | λx. e | e 1 e 2 | fix u. e | () | (e 1 , e 2 ) | fst(e) | snd(e) | c(e) | case e of ms Matches ms ::= · | c(x) ⇒ e|ms Values v : of type δ. This means expressions c(e) are checked against a type, while the subject of a case must synthesize its type. Assuming constructors have type A → δ, this yields the following rules.
We have elided here a syntactic condition that the left-hand sides of a case expression with subject δ cover all constructors for a type δ. Note that in the elimination rule (δE), we move from e ↑ δ to x:A (which may be read x↑A), checking each branch against B.
In addition we have fixed points, which involve both directions: to check fix u. e ↓ A, we assume u:A (which should be read u↑A) and check e against A. Here we have a new form of variable u that does not stand for a value, but for an arbitrary term, because the reduction form for fixed point expressions reduces fix u. e to [fix u. e / u] e (the substitution of fix u. e for u in e). We do not exploit this generality here, but our design is clearly consistent with common syntactic restriction on the formation of fixed points in call-by-value languages.
The syntax and semantics of our core language is given in Figure  1. A capital E denotes an evaluation context-a term with a hole [ ] representing the part of the term where a reduction may occur. The semantics is a straightforward call-by-value small-step formulation. [e /x] e denotes the substitution of e for x in e. Figure 2 shows the subtyping and typing rules for the initial language. The subtyping rules are standard except for the presence of the context Γ , used by the subtyping rules for index refinements and index quantifiers, which we add in the next section. Variables must appear in Γ , so (var) is a synthesis rule deriving x ↑ A. The subsumption rule (sub) is an analysis rule deriving e ↓ B, but its first premise is a synthesis rule e ↑ A. This means both A and B are available when the subtyping judgment A ≤ B is invoked; no complex constraint management is necessary. For introduction and elimination rules, we follow the principles outlined above. Note that in practice, in applications e 1 e 2 , the function e 1 will usually be a variable or, in a curried style, another application-since we synthesize types for these, e 1 e 2 itself needs no annotation.
Ours is not the only plausible formulation of bidirectionality. Xi [26] used a contrasting style, in which several introduction forms have synthesis rules as well as checking rules, for example: Xi's formulation reduces the number of annotations to some extent; for example, in case (x, y) of . . . the pair (x, y) must synthesize, but under our formulation (x, y) never synthesizes and so requires an annotation. However, ours seems to be the simplest plausible formulation and has a clear logical foundation in the notion of introduction and elimination forms corresponding to constructors and destructors for elements of a type under the Curry-Howard isomorphism. Consequently, a systematic extension should suffice to add further language constructs. Furthermore, any term in normal form will need no annotation except at the outermost level, so we should need annotations in few places besides function definitions. In any case, if a system based on our formulation turns out to be inconvenient, adding rules such as the one above should not be difficult.

PROPERTY TYPES
The types present in the language so far are tied to constructors and destructors of terms. For example, the type A → B is realized by constructor λx. e and destructor e 1 e 2 , related to the introduction and elimination forms of → by a Curry-Howard correspondence.
In this section we are concerned with expressing richer properties of terms already present in the language. The only change to the term language is to add typing annotations, discussed in Section 4; otherwise, only the language of types is enriched: The basic properties are data structure invariants, that is, properties of terms of the form c(e). All other properties are independent of the term language and provide general mechanisms to combine simpler properties into more complex ones, yielding a very general type system. In this paper we do not formally distinguish between ordinary types and property types, though such a distinction has been useful in the study of refinement types [11,10].
Our formulation of property types is fully explained and justified in [9] for a pure type assignment system; here, we focus on the bidirectionality of the rules. We do not extend the operational semantics: it is easiest to erase annotations before executing the program. Hence, type safety follows directly from the result for the type assignment system [9].

Intersections
A value v has type A ∧ B if it has type A and type B. Because this is an introduction form, we proceed by checking v against A and B. Conversely, if e has type A ∧ B then it must have both type A and type B, proceeding in the direction of synthesis. Γ While these rules combine properties of the same term (and are therefore not an example of a Curry-Howard correspondence), the erasure of the terms still yields the ordinary logical rules for conjunction. Therefore, by the same reasoning as for ordinary types, the directionality of the rules follows from logical principles.
Usually, the elimination rules are a consequence of the subtyping rules (via the (sub) typing rule), but once bidirectionality is enforced, this is not the case and the rules must be taken as primitive. Note that the introduction form (∧I) is restricted to values because its general form for arbitrary expressions e is unsound in the presence of mutable references in call-by-value languages [7].

Figure 2: Subtyping and typing in the core language
The subtyping rules for our system are designed following the well-known principle that A ≤ B only if any (closed) value of type A also has type B. Thus, whenever we must check if an expression e has type B we are safe if we can synthesize a type A and A ≤ B. The subtyping rules then naturally decompose the structure of A and B by so-called left and right rules that closely mirror the rules of a sequent calculus. In fact, ignoring Γ for now, we can think of subtyping as a single-antecedent, single-succedent form of the sequent calculus.
We omit the common distributivity rule relating intersection and function types, which is unsound with mutable references [7] and does not directly fit into the logical pattern of our rules.

Greatest Type
A greatest type can be thought of as the 0-ary form of intersection (∧). The rules are simply There is no elimination or left subtyping rule for . Its typing rule is a 0-ary version of (∧I), and the value restriction is also required [9].

Refined Datatypes
In our system, each datatype is refined as in [6,8,9] by an atomic subtyping relation over datasorts δ. Each datasort identifies a subset of values of the form c(v). For example, datasorts true and false identify singleton subsets of values of the type bool. We further refine datatypes by indices drawn from some constraint domain, exactly as in [9] which closely followed Xi and Pfenning [28], Xi [26,27], and Dunfield [8]. The type δ(i) is the type of values having datasort δ and index i.
To accommodate index refinements, we extend Γ to allow index variables a, b and propositions P as well as program variables. Because the program variables are irrelevant to the index domain, we can define a restriction function Γ that yields its argument Γ without program variable typings ( Figure 3). No variable may be declared twice in Γ , but ordering is now significant because of dependencies.
Our formulation, like Xi's, requires only a few properties of the constraint domain: There must be a way to decide a consequence relation Γ | = P whose interpretation is that given the index variable typings and propositions in Γ , the proposition P must hold. Because we have both universal and existential quantifiers over elements of the constraint domain, the constraints must remain decidable in the presence of quantifiers, though we have not encountered quantifier alternations in our examples. There must also be a relation i . = j denoting index equality, and a judgment Γ i : γ whose interpretation is that i has index sort γ in Γ . Note the stratification: terms have types, indices have index sorts; terms and indices are distinct. The proof of safety in [9] requires that | = be a consequence relation, that .
= be an equivalence relation, that · | = ⊥, and that | = and have expected substitution and weakening properties [8]. Each datatype has an associated atomic subtyping relation on datasorts, and an associated sort whose indices refine the datatype. In this paper, the only index sort is the natural numbers N with . = and the arithmetic operations +, −, * . Then Γ | = P is decidable provided the equalities in P are linear.
We add an infinitary definite type Πa:γ. A, introducing an index variable a universally quantified over indices of sort γ. One can also view Π as a dependent function type on indices (instead of arbitrary terms).
Example. Assume we define a datatype of integer lists: a list is either Nil() or Cons(h, t) for some integer h and list t. Refine this type by a datasort odd if the list's length is odd, by a datasort even if it is even. We also refine the lists by their length, so Nil has type 1 → even(0), and Cons has type (Πa:N . int * even(a) → odd(a + 1)) ∧ (Πa:N . int * odd(a) → even(a + 1)). Writing Nil() as Nil, the function The subtyping rule for datatypes checks the datasorts δ 1 , δ 2 and (separately) the indices i, j: To maintain reflexivity and transitivity of subtyping, we require to be reflexive and transitive. We assume the constructors c are typed by a judgment Γ c : A → δ(i) where A is any type and δ(i) is some refined type. Now, however, the type A → δ(i) need not be unique; indeed, a constructor should often have more than one refined type. The rule for constructor application is To derive Γ case e of ms ↓ B, we check that all the matches in ms check against B, under a context appropriate to each arm; this is how propositions P arise. The context Γ may be contradictory (Γ | = ⊥) if the case arm can be shown to be unreachable by virtue of the index refinements of the constructor type and the case subject. In order to not typecheck unreachable arms, we have We also do not check case arms that are unreachable by virtue of the datasort refinements. For a complete accounting of how we type case expressions and constructors, see [8].
The typing rules for Π are By our general assumption, the index variable a added to the context must be new, which can always be achieved via renaming. The directionality of these rules follows our general scheme. As for intersections, the introduction rule is restricted to values in order to maintain type preservation in the presence of effects.
One potentially subtle issue with the introduction rule is that v cannot reference a in an internal type annotation, because that would violate α-conversion: one could not safely rename a to b in Πa:γ. A, which is the natural scope of a. We describe our solution, contextual typing annotations, in Section 4.
The subtyping rules for Π are The left rule allows one to instantiate a quantified index variable a to an index i of appropriate sort. The right rule states that if A ≤ B for an arbitrary b:γ then A is also a subtype of Πb:γ. B. Of course, b cannot occur free in A.
As written, in (ΠL) and (ΠE) we must guess the index i; in practice, we would plug in a new existentially quantified index variable and continue, using constraint solving to determine i. Thus, even if we had no existential types Σ in the system, the solver for the constraint domain would have to allow existentially quantified variables.

Indefinite Property Types
We now have a system with definite types ∧, , Π. The typing and subtyping rules are both orthogonal and internally regular: no rule mentions both and ∧, ( I) is a 0-ary version of (∧I), and so on. However, one cannot express the types of functions with indeterminate result type. A standard example is the filter function on lists of integers: filter f l returns the elements of l for which f returns true. It has the ordinary type filter : (int→bool) → list → list. Indexing lists by their length, the refined type should look like filter : Πn:N . (int→bool) → list(n) → list( ) To fill in the blank, we add dependent sums Σa:γ. A, quantifying existentially over index variables, as in [28,26]. Then we can ex-press the fact that filter returns a list of some indefinite length m as follows 1 : For similar reasons, we also occasionally would like union types and the empty type, which should also be considered indefinite. We discuss unions first.
On values, the binary indefinite type is simply a union in the ordinary sense: if v : A ∨ B then either v : A or v : B. The introduction rules directly express the simple logical interpretation, again using checking for the introduction form.
No restriction to values is needed for the introductions, but, dually to intersections, the elimination must be restricted. A sound formulation of the elimination rule in a type assignment form [9] without a syntactic marker 2 requires an evaluation context E around the subterm of union type. This is where the "third direction" is necessary. We no longer move from terms to their immediate subterms, but when typechecking e we may have to decompose it into an evaluation context E and subterm e . Using the analysis and synthesis judgments we have The 0-ary indefinite type is the empty or void type ⊥; it has no values and therefore no introduction rules. For an elimination rule (⊥E), we proceed by analogy with (∨E): As before, the expression must be an evaluation context E with e in evaluation position. For we had one right subtyping rule; for ⊥, following the principle of duality, we have one left rule: For existential dependent types, the introduction rule presents no difficulties, and proceeds using the analysis judgment.
For the elimination rule, we follow (∨E) and (⊥E): Again, there is a potentially subtle issue: the index variable a must be new and cannot be mentioned in an annotation in E.
The subtyping for Σ is dual to that of Π.

Properties of Subtyping
Our subtyping rules are the same as in [9] except for the addition of products A * B. Since the premises are smaller than the conclusion in each rule, and we assume decidability for the constraint domain, we immediately obtain that Γ A ≤ B is decidable. Reflexivity and transitivity are admissible, which follows quite easily [9].

The Tridirectional Rule
Considering ⊥E to be the 0-ary version of the ∨E for the binary indefinite type, what is the unary version? It is: One might expect this rule to be admissible. However, due to the restriction to evaluation contexts, it is not. As a simple example, Now we can complete the derivation with (ΣI), using 1 + m for k and several straightforward steps.

CONTEXTUAL TYPING ANNOTATIONS
Our tridirectional system so far has the property that only terms in normal form have types. For example, (λx. x)() neither synthesizes nor checks against a type. This is because the function part of an application must synthesize a type, but there is no rule for λx. e to synthesize a type.
But annotations are not as straightforward as they might seem. In our setting, two issues arise: checking against intersections, and index variable scoping.

Checking Against Intersections
Consider the following function, which conses 42 to its argument. cons42 = (λx. (λy. Cons(42, x))()) : (odd → even) ∧ (even → odd) This does not typecheck: λy. Cons(42, x) needs an annotation. Observe that by rule (∧I), cons42 will be checked twice: first against odd → even, then against even → odd. Hence, we cannot write (λy. Cons(42, x)) : (1 → even)-it is correct only when checking cons42 against odd → even. Moreover, we cannot write We need to use 1 → even while checking cons42 against odd → even, and 1 → odd while checking cons42 against even → odd. Exasperatingly, union types are no help here: (λy. Cons(42, x)) : (1 → even) ∨ (1 → odd) is a value of type 1 → even or of type 1 → odd, but we do not know which; following (∨E), we must suppose it has type 1 → even and then check its application to 1, and then suppose it has type 1 → odd and check its application to 1. Only one of these checks will succeed-a different one, depending on which conjunct of (odd → even) ∧ (even → odd) we happen to be checking cons42 against-but according to (∨E) both need to succeed.
Pierce [16] and Reynolds [19] addressed this problem by allowing a function to be annotated with a list of alternative types; the typechecker chooses the right one. Davies followed this approach in his datasort refinement checker, allowing a term to be annotated with (e : A, B, . . . ). In that notation, the above function could be written as cons42 = (λx. ((λy. Cons(42, x)) : 1 → even, 1 → odd)()) : (odd → even) ∧ (even → odd) Now the typechecker can choose 1 → even when checking against 1 → odd. This notation is easy to use and effective but introduces additional nondeterminism, since the typechecker must guess which type to use.

Index Variable Scoping
Some functions need type annotations inside their bodies, such as this (contorted) identity function on lists.
In a bidirectional system, the function part of an application must synthesize a type, but we have no rule to synthesize a type for a λabstraction. So we need an annotation on (λz. x). We need to show that the whole application checks against list(a), so we might try Xi already noticed this problem and introduced a term-level abstraction over index variables, Λa.e, to mirror universal index quantification Πa:γ. A [26]. But this violates the basic principle of property types that the term should remain unchanged, and fails in the presence of intersections. For example, we would expect the reverse function on lists, rev, to satisfy rev : (Πa:N . list(a) → list(a)) ∧ ((Σb:N . list(b)) → Σc:N . list(c)) but the first component of the intersection would demand a termlevel index abstraction, while the second would not tolerate one.

Contextual Subtyping
We address these two problems by a method that extends and improves the notation of comma-separated alternatives. The essential idea is to allow a context to appear in the annotation along with each type: where each context Γ k declares the types of some, but not necessarily all, free variables in e.
In the first approximation we can think of such an annotated term as follows: if Γ k e ↓ A k then Γ (e : Γ 1 A 1 , . . . , Γn An ) ↑ A k if the current assumptions in Γ validate the assumptions in Γ k . For example, the second judgment below is not derivable, since x:odd does not validate x:even (because odd ≤ even).
x:even ((λy . Cons(42, x)) : x:even 1 → odd, x:odd 1 → even) ↑ 1 → odd x:odd ((λy . Cons(42, x)) : x:even 1 → odd, In practice, this should significantly reduce the nondeterminism associated with type annotations in the presence of intersection. However, we still need to generalize the rule in order to correctly handle index variable scoping. Returning to our earlier example, we would like to find an annotation As allowing us to derive to make the typing annotation self-contained. Now, when we check if the current assumptions for x validate local assumption for x, we are permitted to instantiate b to any index object i. In this example, we could substitute a for b. As a result, we end up checking (λz. x) ↓ 1 → list(a), even though the annotation does not mention a. Note that in an annotation e : (Γ 0 A 0 ), As, all index variables declared in Γ 0 are considered bound and can be renamed consistently in Γ 0 and A 0 . In contrast, the free term variables in Γ 0 may actually occur in e and so cannot be renamed freely.
These considerations lead to a contextual subtyping relation : which is contravariant in the contexts Γ 0 and Γ . It would be covariant in A 0 and A, except that in the way it is invoked, Γ 0 , A 0 , and Γ are known and A is generated as an instance of A 0 . This should become more clear when we consider its use in the new typing rule

Figure 5: Contextual subtyping
where we regard the annotations as unordered (so Γ 0 A 0 could occur anywhere in the list). In the bidirectional style, Γ , e, Γ 0 , A 0 and As are known when we try this rule. While finding a derivation of (Γ 0 A 0 ) (Γ A) we generate A, which is the synthesized type of the original annotated expression e, if in fact e checks against A. It is also possible that (Γ 0 A 0 ) (Γ A) fails to have a derivation (when Γ 0 and Γ have incompatible declarations for the term variables occurring in them), in which case we need to try another annotation (Γ k A k ).
The formal rules for contextual subtyping are given in Figure 5. Besides the considerations above, we also must make sure that any possible assumptions P about the index variables in Γ 0 are indeed entailed by the current context, after any possible substitution has been applied (this is why we traverse Γ 0 from left to right).
While the examples above are artificial, similar situations arise in ordinary programs in the common situation when local function definitions reference free variables. Two small examples of this kind are given in Figure 6 presented in the style of ML; we have omitted the evident constructor types and, following the tradition of implementations such as Davies', written typing annotations inside bracketed comments.
The essence of the completeness result we prove in Section 4.5 is that annotations can be added to any term that is well typed in the type assignment system to yield a well typed term in the tridirectional system. For this result to hold, must be reflexive,

in a judgment
Γ (e : (Γ 1 A 1 , . . . , Γn An )) ↑ A we must be able to consistently rename index variables in Γ , all Γ k , and e. This different treatment of index variables and term variables arises from the fact that index variables are associated with property types and so do not appear in expressions, only in types.
Reflexivity (together with proper α-conversion) is sufficient for completeness: in the proof of completeness, where we see Γ e : A we can simply add an annotation (Γ A). But it would be absurd to make programmers type in entire contexts-not only is the length impractical, but whenever a declaration is added every contextual annotation in its scope would have to be changed! Reflexivity of follows easily from the following lemma.

Soundness
Let |e| denote the erasure of all typing annotations from e.
PROOF. By straightforward induction on the derivation.

Completeness
We cannot just take a derivation Γ e : A in the type assignment system and obtain a derivation Γ e ↑ A in the tridirectional system. For example, λx. x : A → A for any type A, but in the tridirectional system λx. x does not synthesize a type. However, if we add a typing annotation, we can derive Clearly, the completeness result must be along the lines of "If Γ e : A, then there is an annotated version e of e such that Γ e ↑ A." To formulate this result (Corollary 12, a special case of Theorem 11) we need a few definitions and lemmas. DEFINITION 6. e lightly extends a term e, written e e iff e is e with zero or more typing annotations added to lists of typing annotations already present in e. That is, we can replace (e : As) with (e : As, A ), but cannot replace e with (e : A ).

PROPOSITION 7.
and are reflexive and transitive.
PROOF. Obvious from the definitions. LEMMA 8. If e value and e e then e value.
PROOF. By a straightforward induction on e (in the base case, making use of (v : As) value).
PROOF. By induction on the derivation of the typing judgment. All cases are straightforward: either e and e must be identical (for instance, for (1I)), or we apply the IH to all premises, which leads directly to the result.
Recall that the rule (∧I) led to the need for more than one typing annotation on a term. It should be no surprise, then, that the (∧I) case in the completeness proof is interesting. Applying the induction hypothesis to each premise v :

THE LEFT TRIDIRECTIONAL SYSTEM
In the simple tridirectional system, the contextual rules are highly nondeterministic. Not only must we choose which contextual rule to apply, but each rule can be applied repeatedly with the same context E; for (direct), which does not even break down the type of e , this repeated application is quite pointless. The system in this   Figure 9: Connections between our type systems section has only one contextual rule and disallows repeated application. Inspired by the sequent calculus formulation of Barbanera et al. [2], it replaces the contextual rules with one contextual rule (directL), closely corresponding to (direct), and several left rules, shown in the upper right hand corner of Figure 8. In combination, these rules subsume the contextual rules of the simple tridirectional system. The typing judgments in the left tridirectional system are where ∆ is a linear context whose domain is a new syntactic category, the linear variables x, y and so forth. These linear variables correspond to the variables introduced in evaluation position in the (direct) rule, and appear exactly once in the term e, in evaluation position. We consider these linear variables to be values, like ordinary variables. The rule (directL) is the only rule that adds to the linear context, and is the true source of linearity: x appears exactly once in evaluation position in E[x]. It requires that the subterm e being brought out cannot itself be a linear variable, so one cannot bring out a term more than once, unlike with (direct).
To maintain linearity, the linear context is split among subterms. For example, in ( * I) (Figure 8), the context ∆ = ∆ 1 , ∆ 2 is split between e 1 and e 2 . To maintain the property that linear variables appear in evaluation position, in rules such as (→I) that type terms that cannot contain a variable, the linear context is empty.
After some preliminary definitions and lemmas, we prove that this new left tridirectional system is sound and complete with respect to the simple tridirectional system from Section 3. (See also Figure 9). PROOF. Straightforward.

DEFINITION 17. A renaming ρ is a variable-for-variable substitution from one set of variables (dom(ρ)) to another, disjoint set.
When a renaming is applied to a term, [ρ]e, it behaves as a substitution, and can substitute the same variable for multiple variables. Unlike a substitution, however, it can also be applied to contexts. A renaming from linear variables to ordinary program variables, ρ = x/x, . . . , may be applied to a linear context ∆: [ρ]∆ yields an ordinary context Γ by renaming all variables in dom(∆). In the other direction, a renaming ρ from ordinary program variables to linear variables may be applied to an ordinary context Γ : The condition ∆ e is trivially satisfied if ∆ = · and e contains no linear variables, which is precisely the situation for the whole program.
PROOF. By induction on the typing derivation. We use Lemma 16 to satisfy the linearity condition whenever we apply the IH. Most cases are completely straightforward, except for the rules not present in the simple tridirectional system.
For (var), it is given that dom(ρ) ⊇ dom(∆), so we can apply (var). For (directL), use the IH on the first premise, let x be new, and use the IH on the second premise with the renaming ρ, x/x; apply properties of substitution and weakening to yield derivations to which (direct) can be applied.

Completeness
We now show completeness: If a term can be typed in the simple tridirectional system, it can be typed in the left tridirectional system. First, a small lemma: However, this fails for the rules that are absent or modified in the left tridirectional system: (direct), (⊥E), (∨E), (ΣE). In each of the cases for these rules, there are two subcases: • If the subterm e is not a variable renamed by ρ, then we apply the IH to the premise typing e , make a new linear variable x, apply the IH to the contextual premises as needed, apply the corresponding left rule (or do nothing in the (direct) case) to show E[x] ↓ L C, then apply (directL).
• If e is a variable in dom(ρ), we apply the IH to all premises, apply the corresponding left rule (or do nothing in the (direct) case), then use Lemma 19.

Decidability of Typing
PROOF. We impose an order < on two judgments J 1 = Γ 1 ; ∆ 1 e 1 ↓↑ A 1 and J 2 = Γ 2 ; ∆ 2 e 2 ↓↑ A 2 . When ordering terms, we consider linear variables to be smaller than any other terms; for example, (x, e 2 ) is smaller than (y, e 2 )). When ordering types (that is, type expressions), we consider all index expressions to be of equal size.
The order is defined as follows.
1. If e 1 is smaller than e 2 then J 1 < J 2 . If e 1 is the same size as e 2 : 2. If the directions of the judgments differ, the synthesis judgment is smaller than the checking judgment. If the directions are the same: 3. If both judgments are checking judgments and A 1 is smaller than A 2 then J 1 < J 2 . If both judgments are synthesis judgments, Γ 1 = Γ 2 , ∆ 1 = ∆ 2 , A 1 is as small as, or smaller than, some type in (Γ 1 ; ∆ 1 ), and A 1 is larger than A 2 , then J 1 < J 2 . Otherwise: 4. If the number of times any of the type constructors ∨, Σ, ⊥, ∧, Π, appear in ∆ 1 is less than the number of times they appear in ∆ 2 then J 1 < J 2 .
Now we show that for every rule, each premise is smaller than the conclusion. For most premises, the first criterion alone makes the premise smaller. The second criterion is for (sub). The third criterion is needed for rules such as (ΠI) and (ΠE). Note that a synthesis judgment whose type expression becomes larger is considered smaller! Synthesis judgments eventually "bottom out" at rules like (ctx-anno) and ( * E 1 ), in which the term becomes smaller, or at rules (var), (fixvar) or (var), where the type synthesized is taken from Γ or ∆. Since all the type expressions in Γ and ∆ are finite, there is no problem. The fourth criterion is for the left rules, where the term, direction, and type do not change.
The second premise of (directL) is smaller than its conclusion because we consider linear variables to be the smallest terms and (directL) does not permit e to be a linear variable.

Type Safety
If ·; · e ↓ L A in the left tridirectional system, from Theorem 18 we know · e ↓ A. Then by Theorem 3, · |e| : A in our type assignment system [9]. That is, type erasure suffices to get a typing derivation in the type assignment system. It follows from [9]'s Theorem 3, Type Preservation and Progress, that |e| either diverges or evaluates to a value of type A.

RELATED WORK
Refinements, intersections, unions. The notion of datasort refinement combined with intersection types was introduced by Freeman and Pfenning [11]. They showed that full type inference was decidable under the so-called refinement restriction by using techniques from abstract interpretation. Interaction with effects in a call-by-value language was first addressed conclusively by Davies and Pfenning [7] who introduced the value restriction on intersection introduction, pointed out the unsoundness of distributivity, and proposed a practical bidirectional checking algorithm. Index refinements were proposed by Xi and Pfenning [28]. As mentioned earlier, the necessary existential quantifier Σ led to difficulties [26] because elaboration must determine the scope of Σ, which is not syntactically apparent in the source program. Xi addressed this by translating programs into a let-normal form before checking index refinements, which is akin to typechecking the original term in evaluation order. Because of the specific form of Xi's translation, our tridirectional system admits more programs, even when restricted to just index refinements and quantifiers. Nonetheless, we conjecture that Xi's idea of traversing the entire program strictly in evaluation order is applicable in our significantly more complex setting to eliminate the nondeterminism inherent in the (directL) rule; we plan to pursue this in further research.
Intersection types [4] were first incorporated into a practical language by Reynolds [19]. Pierce [17] gave examples of programming with intersection and union types in a pure λ-calculus using a typechecking mechanism that relied on syntactic markers. The first systematic study of unions in a type assignment framework [2] identified several issues, including the failure of type preservation even for the pure λ-calculus when the union elimination rule is too unrestricted. It also provided a framework for our more specialized study of a call-by-value language with possible effects.
Some work on program analysis in compilation uses intersection and union types to infer control flow properties [24,15]. Because of the goals of these systems for program analysis and control flow information, the specific forms of intersection and union types are quite different from ours. Soft typing systems designed for type inference under dynamic typing [3] are somewhat similar, allowing intersection, union, and even conditional types [1]. Again, due to the different setting and goal, the technical realization differs substantially from our work.
Partial inference systems. Our system shares several properties with Pierce and Turner's local type inference [18]. Their language has subtyping and impredicative polymorphism, making full type inference undecidable. Their partial inference strategy is formulated as a bidirectional system with synthesis and checking judgments, in a style not too far removed from ours. However, in order to handle parametric polymorphism without using nonlocal methods such as unification, they infer type arguments to polymorphic functions, which seems to substantially complicate matters. Hosoya and Pierce [12] further discuss this style, particularly its effectiveness in achieving a reasonable number of annotations.
Our system does not yet have parametric polymorphism. Prior research, either with (in [26]) or without (in [7]) a syntactic distinction between ordinary and property types, is not conclusive. However, the work on local type inference suggests that, at least, prefix polymorphism in the style of ML should be amenable to a consistent treatment with bidirectional rules.

Principal typings.
A principal type of e is a type that represents all types of e-in some particular context Γ . A principal typing [13] of e is a pair (Γ, A) of a context and a type, such that (Γ, A) represents all pairs (Γ , A ) such that Γ e : A . These definitions depend on some idea of representation, which varies from type system to type system, making comparisons between systems difficult. Wells [25] improved the situation by introducing a general notion of representation. Since full type inference seems in any case unattainable, we have not investigated whether principal typings might exist for our language. However, the idea of assigning a typing (rather than just a type) to a term appears in our system in the form of contextual typing annotations, enabling us to solve some otherwise very unpleasant problems regarding the scope of quantified index variables.

CONCLUSION
In [9], we developed a type assignment system with a rich set of property type constructors. That system is sound in a standard callby-value semantics, but is inherently undecidable. In this paper, by taking a tridirectional version of the type assignment system, we have obtained a rich yet decidable type system. Every program well-typed under the type assignment system has an annotation with contextual typings that checks under the tridirectional rules. Contextual typing annotations should be useful in other settings, such as systems of parametric polymorphism in which subtyping is decidable.
In order to show decidability, and as a first important step towards a practical implementation, we also presented a less nondeterministic left tridirectional system and proved it to be decidable and sound and complete with respect to the tridirectional system.
We are in the process of formulating a let-normal version of the left tridirectional system. Such a system would drastically reduce the nondeterminism in (directL) by forcing the typechecker to traverse subterms in evaluation order, while being sound and complete with respect to the left tridirectional system.
Once this is done, we plan to develop a prototype implementation of the let-normal system that should help us answer questions regarding the practicality of our design on realistic programs. The main questions will be (1) if the required annotations are reasonable in size, (2) if type checking is efficient enough for interesting program properties, and (3) if the typing discipline is accurate enough to track properties in complex programs. The preliminary experience with refinement types, including both datasort refinements [5] and index refinements [28], gives reason for optimism, but more research and experimentation is needed.