Type inference rules

The inference judgment, (P,Γ wE : T ), consists of the term to be typed, E , that eventually is assigned type T in a type environmentΓ, and a prototype P representing parts of the type of E that are inherited from the context. P can be treated as a regular type, potentially having type holes, ?, representing the unknown parts. The prototype fully encapsulates the concept of colored types and their partial type information propagation.

Figure 2.4 presents a selection of the most interesting inference rules for Colored Type Infer- ence, which follow naturally from the formalization of the external language. While simple Local Type Inference distinguished synthesis and type checking of type annotations through separate rules, the concept of a prototype and holes in it combines it. Moreover, Colored Lo- cal Type Inference allows for propagating strictly more type information between the nodes of the terms; in the simple Local Type Inference only ? or fully defined types, e.g., I nt→ Int, would be allowed as prototypes, but no partial ones, e.g., I nt→ ?.

For example, for some function g of type∀a.((Int → a) → a) applied to an anonymous func- tion (fun( x ) x) in ‘g (fun( x ) x), the Colored Type Inference is capable of inferring the de- sired type of the application in the derivable judgment (I nt → ?,  w g (fun( x ) x) : I nt ). The type of the parameter of x in the anonymous functionfun( x ) x is inherited from the context, and the result type is synthesized from the body of the function. On the other hand, when some function h of type∀a.((a → a) → a) is applied to the same anonymous function in h (fun( x ) x), the inference fails to come up with the right type of the parameter, as repre- sented by a non-derivable (?→ ?,  wfun( x ) x : T ) fragment of the type derivation tree (T is unknown). Such type inference, or lack thereof, follows the expectation of the user, since the context of the function application has to provide enough type information for the type annotation not to be guessed.

To avoid soundness problems, any type assigned to the term has to conform to the type ex- pected by the type checking context (whether the latter contributed to the inference of the type or not). Matching between the expected inherited type and the synthesized type is ex- pressed through a operator. The T  P notation means that either T is structurally equal to P , with ? filled by some arbitrary types, or we can find the smallest supertype of T which is structurally equal to P . The operation T P is the dual of T  P, where the greatest subtype of T is structurally equal to P .

For brevity, we now only discuss a selection of the type inference rules that will be analyzed in our type debugging formalization, i.e., (abs),(abst p)and(app), and refer the reader to

Chapter 2. Preliminaries (VAR) P,Γ wx : Γ(x)  P (sel){x : P },Γ  w_{F : {x : T }} P,Γ w_{F.x : T} (abs) P,Γ,a,x : T  w_{E : S}

∀a.T → P, Γ w_{fun(x)E : ∀a.T → S} (abst p,?)

?,Γ,a,x : T wE : S ?,Γ w_fun_a_{(x : T )E :∀a.T → S}

(abst p)

P,Γ,a,x : T wE : S

∀a.P → P_{,Γ }w_fun_a_{(x : T )E :∀a.T → S  ∀a.P → P}

(appt p) ?,Γ wF :∀a.S → T [R_/a] S,Γ wE : [R_/a] S P,Γ w_F_R_{(E ) : [}R_/a] T P (app) ?,Γ wF :∀a.S → T [?_{/a] S,}Γ w_{E : S} aS<: S ⇒ C1 aT<:   P ⇒ C2 P,Γ w_{F ( E ) :σ} C1∪C2,TT P (rec)(P1,Γ  w_F 1: T1) ... (Pm,Γ wFm: Tm) (, Γ wFm+1: Tm+1) ... (, Γ wFn: Tn) {x1: P1, ..., xm: Pm},Γ w{x1= F1, ..., xn= Fn}: {x1: T1, ..., xm: Tm}

Figure 2.4: A fragment of the type inference rules that realize the (P,Γ wE : T ) inference judgment (from [Odersky et al., 2001, pg. 11])

The ability to infer the type of the parameter of the abstraction in the ‘g (fun( x ) x)example is formally defined in the rule(abs); the rule requires a ?-free type T in the propagated pa- rameter part of the prototype,∀a.T → P. The result type of the prototype, P, does not directly influence the inferred of the type of the function. Indirectly, however, the P part is used in inferring the type of the body of the function, as expressed by an assignment of P as input to the rule’s only premise. This agrees with the intuition of the Colored Type System; the result type of the inherited function type can only impose a requirement on the type of the body of the abstraction and that information is only passed around between the adjacent nodes of the type derivation tree.

The(abst p)and(abst p,?)rules apply to the abstraction term with the explicit type of the

parameter,funa(x : T )E . The shape of the propagated type information (∀a.P → Pand ?, respectively) allows to disambiguate the application of the rules to the abstraction term. Thus, together both of the rules correspond to the(ABSt p)rule of the Colored Type System in

Figure 2.3, where the assigned type could be both, synthesized and inherited (we recall from the subtyping rules of the Colored Type System that∧(∀a. T → S) ≤ ∨(∀a. T → S)). Similarly as in the Colored Type System, the most complicated type inference rule,(app), in- fers the type of function application with elided type arguments. The first premise, (?, Γ w F : ∀a.S → T ), requires that the synthesized type of the function is a function type. The in- ferred type of the function directly corresponds to the type assigned to the function in the (APP)rule of the Colored Type System, i.e., Γ cF : ∀a.∨(_∧S→_∧T ); in both cases the func- tion type constructor is enforced by the context of the function application.

The synthesized type elements of the function provide partial type information for inferring 24

2.1. Colored Local Type Inference (CG-Top)V _XT<:  ⇒  (CG-Bot)V _X⊥ <: T ⇒  (CG-Upper)Y∈ X S ⇓ V _{T fv(S)∩ X = } V _XY<: S ⇒{⊥<:Y<:T} (CG-Lower) Y∈ X S ⇑VT fv(S)∩ X =  V _XS<: Y ⇒{T<:Y<:} (CG-Refl) Y∈ X V _XY<: Y ⇒  (CG-Fun) V∪ a XT<: R ⇒ C V∪ a XS<: U ⇒ C a∩ (V ∪ X ) V _X∀a.R → S <: ∀a.T → U ⇒ C∧C

Figure 2.5: A complete constraint generation algorithm as defined by the rules of the V aS<: T ⇒ C judgment in [Pierce and Turner, 2000, pg. 12].

the type of the other term elements in the function application. The type of the argument E can therefore be inferred with the help of the prototype involving the parameter of the func- tion type, with all the unknown type variables substituted by wildcard constants, i.e., [?_/

a] S;

the substitution directly corresponds to the structural equality Sa ∨S premise, modulo the

uninstantiated type variables, in the(APP)rule of the Colored Type System.

In order to infer concrete instantiations for type variables, the rule collects local type con- straints using theaS<: T ⇒ C judgment. The constraints originate from the two subtyping

relations and correspond directly to the subtyping relations in the(APP)rule that specify the conditions for guessing the minimal set of type argument values. The next section describes in detail the process of collecting and solving of type constraints that leads to optimal type arguments.