Type Inference with Constrained Types Martin Sulzmann Yale University Department of Computer Science New Haven, CT 06520-8285
Martin Odersky University of South Australia School of Computer and Information Science The Levels, South Australia 5095
[email protected]
[email protected]
Martin Wehr University of Edinburgh Laboratory for Foundations of Computer Science
[email protected]
Research Report YALEU/DCS/RR-1129, April 1997
Abstract
types can be found in [Jon92]. We discuss Jones approach in more detail in the section about related work. In this paper we present a general framework HM(X) Remy [Rem92] extends the Hindley/Milner type system for Hindley/Milner style type systems with constraints. with a sorted equational theory. His approach is very HM(X) stays in the tradition of the Hindley/Milner close in spirit to ours. But he restricts his attention type system. Type systems in HM(X) are sound unto equality constraints whereas our approach gives a der a standard untyped compositional semantics that foundation for more general constraint systems. Exguarantees the slogan `well{typed programs can not go tensions of Hindley/Milner with constraints are also inwrong'. Furthermore, we can give a generic type infercreasingly popular in program analysis [DHM95, TJ92]. ence algorithm for HM(X). Under sucient conditions Palsberg [Pal95] gave an ecient inference algorithm for on X, type inference will always compute the principal a calculus of objects. The main feature of his system type of a term. An instance of our framework which is that he does not use the Hindley/Milner approach to deals with polymorphic records is discussed. Also, we type inference. It remains to be seen how his approach give a subtyping extension SHM(X) of our HM(X) sysis related to ours. tem. In particular, the type inference algorithm for Even though these type systems use di erent consubtypes computes principal types. Simpli cation of straint domains, they are largely alike in their typethe constraints inferred by the type inference algorithm theoretic aspects. In this paper we present a general is discussed for HM(X) and SHM(X). framework HM(X) for Hindley/Milner style type systems with constraints, analogous to the CLP(X) framework in constraint logic programming [JM94]. Partic1 Introduction ular type systems can be obtained by instantiating the parameter X to a speci c constraint system. The HindWe study an extension of the Hindley/Milner [Mil78] ley/Milner system itself is obtained by instantiating X system with constraints. Cardelli/Wegner [CW85] gave to the trivial constraint system. an early survey about general research directions. ReyBy and large, the treatment of constraints in type nolds [Rey85] and Mitchell [Mit84] are foundational pasystems has been syntactic : constraints were regarded pers that develop basic concepts of constraints and subas sets of formulas, often of a speci c form. On the typing. There are examples for extensions of the Hindother hand, constraint programming now generally uses ley/Milner system with records [Oho95, Rem89], overa semantic de nition of constraint systems, taking a loading [Jon92, Kae92, VHJW96, NP93, CHO92, OWW95], + constraint system as a cylindric algebra with some adand subtyping [CCH 89, BSvG95, AW93, EST95b]. A ditional properties [HMT71, Sar93]. Cylindric algebras general extension of the Hindley/Milner with quali ed de ne a projection operator that binds some sub Supported by a Yale University Fellowship.
9
set of variables in the constraint. In the usual case where constraints are boolean algebras, projection corresponds to existential quanti cation. Following the lead of constraint programming, we treat a constraint system as a cylindric algebra with a projection operator. Projection is very useful for our purposes for two reasons: First, projection allows us to formulate a logically pleasing and pragmatically useful rule ( Intro) for quanti er introduction:
always yields a \best" solution, if there is a solution at all. For those constraint systems meeting this condition, we present a generic type inference algorithm that will always yield the principal type of a term. Our work generalizes Milner's results to systems with non{trivial constraints and makes it thus possible to experiment with new constraint domains without having to invent yet another type inference algorithm and without having to repeat the often tedious proofs of soundness and completeness of type inference. We discuss an instance of our HM(X) framework that deals with polymorphic records. Namely, we show how to encode the record calculus of Ohori [Oho95] in terms of our system. Furthermore, we give an extension SHM(X) of our HM(X) framework that deals with subtypes. The concept of subtyping is of great importance in many record and object calculi. We enrich our constraint system with a subtype predicate between types and , denoted by ( ). In SHM(X) we additionally have the subsumption rule. We provide an extension of our generic type inference algorithm that computes principal types for SHM(X) type systems. Previous approaches towards type inference with subtypes [AW93, EST95b] lack this property. In case of subtyping, simplifying constraints [Jon95, Pot96, EST95a] becomes an important issue. Type inference simply accumulates all constraint problems and ends up in a large constraint set. One reason is that uni cation{based approaches to type inference with subtypes do not seem to apply. We discuss simpli cation for HM(X) and SHM(X). The rest of this paper is structured as follows: We give a characterization of constraint systems in Section 2. A general framework HM(X) for Hindley/Milner style type systems with constraints is presented in Section 3. Section 4 establishes conditions on the constraint system so that type inference is feasible and a principal types theorem holds. An instance of our framework with polymorphic records is considered in Section 5. In Section 6 we discuss a general condition under which we get instances of our HM(X) framework for free. We discuss an extension SHM(X) of HM(X) with subtypes in section 7. Simpli cation is discussed in Section 8 The relationship to previous approaches is considered in Section 9. Section 10 concludes.
8
( Intro) C D; ? 8
^
e: C ^ 9 :D; ? `
`
62 fv(C ) [ fv(?) e : 8 :D )
where C and D are constraints over the type variables in the type context ? and the type scheme . Second, projection is an important source of opportunities for simplifying constraints [Jon95, Pot96, EST95a]. In our framework, simplifying means changing the syntactic representation of a constraint without changing its denotation. For example, the subtyping constraint :( ) ( ) can safely be simpli ed to 9
^
0
( )
since the denotation is the same for both constraints. Without the projection operator, the two constraints would be di erent, since one restricts the variable while the other does not. Two of the main strengths of the Hindley/Milner system are a type soundness result and the existence of a type inference algorithm that computes principal types. HM(X) stays in the tradition of the Hindley/Milner type system. Type systems in HM(X) are sound under a standard untyped compositional semantics provided the underlying constraint system X is sound. This result can be summarized in the slogan `well{typed programs can not go wrong'. One of the key ideas of our paper is to present sucient conditions on the constraint domain X so that the principal types property carries over to HM(X). The conditions are fairly simple and natural. For those constraint systems meeting the conditions, we present a generic type inference algorithm that will always yield the principal type of a term. To this purpose, we represent the typing problem itself as a constraint. Generally, the constraint system X needs to be rich system to express all constraint problems. On the left hand side of the turnstyle and in type schemes we only admit a subset of constraints in X that are in so{called solved form. The task of type inference is then to split a typing problem into a substitution and a residual constraint in solved form. This we call constraint normalization. We require that normalization
0
2 Constraint systems We present a characterization of constraint systems along the lines of Henkin [HMT71] and Saraswat [Sar93]. We restate the de nitions of a simple and a cylindric constraint system. Furthermore, we introduce the new no2
tion of a term constraint system.
The next lemma states that the projection operator does not in uence the satis ability of a constraint. De nition 1 (Simple Constraint System) A simple Lemma 2 Let C be a constraint. Then C is satis able constraint system is a structure ( ; e ) where is a i :C is satis able. non{empty set of tokens or (primitive) constraints. We also refer to such constraints as predicates. The relation We now introduce a much more expressive constraint e p is a decidable entailment relation where p
system. We want to deal with types and substitutions. is the set of nite subsets of . We call C p a conDe nition 5 (Types) A type is a member of straint set or simply a constraint. e =Term() where Term() is the term algebra built A constraint system ( ; ) must satisfy for all conup from a signature = (Var, Cons). Var is a set of straints C; D p : variables and Cons is a set of type constructors containC1 C e P whenever P C and ing at least the function constructor of arity 2. C2 C e Q whenever A type context t[] is a type with a hole and is de ned C e P for all P D and D e Q by t[] ::= [] t[] t[] T t[] : : : t[] We extend e to be a relation on p p by: C e D where and T stands for a type constructor in i C e P for every P D. Furthermore, we de ne Cons besides . e e e e C = D i C D and D C . The term C is e e an abbreviation for C and true = P P De nition 6 (Substitutions) A substitution is an represents the true element. idempotent mapping from a set of variables Var to the term algebra Term(). Let id be the identity substituBy the following lemma we can identify the minimal tion. constraint as a representation for true. De nition 7 (Term Constraint System) A term conLemma 1 Given a simple constraint system constraint straint system = ( ; e ; Var; Var ) ( ; e ). Then true =e . over a term algebra is a cylindric constraint system Remark 1 For simplicity, we omit set notation for con- with predicates of the form straints. We connect constraints by instead of the p( 1 ; : : : ; n ) ( i ) union operator . Also, we omit to enclose simple consuch that the following holds: straints P in opening and closing braces. That means, P Q is an abbreviation for P Q. For each pair of types ; there is an equality predicate ( = ) in , which satis es: De nition 2 (Cylindric Constraint System) A cyline ( = ) D1 e dric constraint system is a structure = ( ; D2 ( = ) e ( = ) ; Var; Var ) such that: D3 ( = ) ( = ) e ( = ) e D4 ( = ) :C ( = ) e C ( ; ) is a simple constraint system, D5 ( = ) e (t[ ] = t[ ]) Var is an in nite set of variables, where t[] is a type context For each variable Var, : p p
For each predicate P , is an operation satisfying: D6 [ = ]P =e :P ( = ) E1 C e :C e e where fv( ) E2 C D implies :C :D e E3 :(C :D) = :C :D Remark 2 Conditions D1 { D4 are the conditions imE4 : :C =e : :C posed on a cylindric constraint system with diagonal elements, which is usually taken as the foundation of conThe next de nition de nes the free type variables straint programming languages. D4 says that equals can fv(C ) of a constraint C . be substituted for equals; it is in e ect the Leibniz prinDe nition 3 (Free Variables) Let C be a constraint. ciple. D5 states that (=) is a congruence. D6 connects the syntactic operation of a substitution over predicates Then fv(C ) = :C =e C . with the semantic concepts of projection and equality. We now de ne satis ability of a constraint. Substitution is extended to arbitrary constraints in the De nition 4 (Satis ability) Let C be a constraint. canonical way: Then C is satis able i e fv(C ):C . [ = ](P1 : : : Pn ) = [ = ]P1 : : : [ = ]Pn : `
9
`
2
T
`
T
2
`
2
!
`
`
2
`
j
`
`
`
`
;
f
j;
`
j
!
`
`
!
2 T
2
`
j
g
;
T C ST
`
;
`
f9
T
^
2 T
[
^
f
g[ f
g
0
0
CCS
f9
j
2
T C ST
`
`
`
g
^
`
^ 9
`
0
2
9
^
`
0
`
!
`
9
9
`
9
9
9
^ 9
9
9
f
9
j9
`
^
62
9
^ 9
9
6
g
`
9
^
3
^
^
^
j
2
g
(Var)
C; ? C; ?
(Equ)
`
`
x : (x : 2 ?)
e : `e ( = ) C; ? ` e : 0
0
C; ?x :x : ` e : C; ?x ` x:e : ! 0
(Abs) C; ?
(App)
C; ?x
(Let)
e 1 : 1 ! 2 C; ? C; ? ` e1e2 : 2
`
`
e:
C; ?x
`
8
( Elim) C; ? 8
`
e 2 : 1
C; ?x :x : ` e : let x = e in e : 0
0
C ^ D; ? ` e : C ^ 9 :D; ?
( Intro)
0
`
0
0
62 fv(C ) [ fv(?) e : 8 :D )
e : 8 :D ) C `e [ = ]D C; ? ` e : [ = ] 0
`
0
Figure 1: Logical type system
3 The HM(X) framework
The intention of a term constraint system is to express uni cation problems through the equality predicate (=). A term constraint system is a very powerful constraint system. In the latter we distinguish a speci c subset of constraints in . We denote this set by . We say the constraints in are in solved form. We put in general the following conditions on : T C ST
This section describes a general extension HM(X) of the Hindley/Milner type system with a term constraint system X over a term algebra . We denote the set of solved constraints in X by . In our type system we only admit constraints in . Our development is similar to the original presentation [DM82]. We work with the following syntactic domains. Values v ::= x x:e Expressions e ::= v ee let e = x in e Types :: T Type schemes ::= :C
T C ST
T
T C ST
S
S
S
S
S
S1 S2 Each C is satis able S3 If C and C e ( = ) then e ( = ) S4 If C then :C Remark 3 Condition S3 prohibits equality predicates in . Equality predicate should be resolved in by a kind of uni cation. Condition S4 enforces that is S T C ST
2 S
2 S
2 S
0
`
9
0
`
j
2 S
S
j
j
j8
S
j
!
j
)
This generalizes the formulation in [DM82] in two respects. First, types are now members of an arbitrary term algebra, hence there might be other constructors besides , with possibly non{trivial equality relations. Second, type schemes :C now include a constraint component C , which restricts the types that can be substituted for the type variable . On the other hand, the language of terms is exactly as in [DM82]. That is, we assume that any language constructs that make use of type constraints are expressible as prede ned values, whose names and types are recorded in the initial type environment ?0 . We often use vector notation for type variables in
S
closed under projection. For a special instance of a term constraint system T C S we might put some further restrictions on the set S of constraints in solved form. Some basic lemmas follow. Lemma 3 (Normal Form) Let C be a constraint and = [ = ] be a substitution. Then C =e 9 :C ^ ( 1 = 1 ) ^ : : : ^ ( n = n ) Lemma 4 (Substitution) Let C; D be constraints and be a substitution such that C `e D. Then T
!
8
2 S
C `e D
4
)
type schemes. The term :D is an abbreviation for 1:true : : : n :D and :D for 1 : : : : n :D. The typing rules can be found in Figure 1. The most interesting rules are the ( Intro) rule and the ( Elim) rule. By rule ( Intro) we quantify some type variables. We often use vector notation for type variables in type schemes. The term :D is an abbreviation for 1:true : : : n :D and :D for 1 : : : : n :D. Rule (Equ) becomes important if there are type constructors in the term algebra with non{trivial equality relations. The other rules are a straightforward extension of the Hindley/Milner rules. 8
8
9
)
we assume that any language constructs that make use of type contraints are expressible as prede ned values, whose names and types are recorded in the initial type environment. [ x] = (x)
)
8
)
9
9
8
8
8
8
8
9
)
[ u:e] = v:[ e] [u := v]
)
8
)
[ e e ] = if [ e] 0
9
9
0
De nition 8 (Typing Judgments) Let C be a constraint in S , ? a type environment and a type scheme. Then C; ? ` e : is a typing judgment i C; ? ` e : can be derived by application of the typing rules.
!
8
e ; Var; f9 j 2 Varg)
be the minimal term constraint system. contains only primitive constraints of the form ( = ) where and are types. We de ne the set S of constraints in solved form as ftrueg. Then the Hindley/Milner system is equivalent to HM(1). 0
0
j
2
)
`
2
g
g
)
)
2
C
type variables , constraints C 2 S , if `e 9 :C then there is a monotype such that `e 9 :( = ) ^ C .
The soundness proof is based on an ideal semantics of types which is a direct extension of the semantics in [Mil78]. The meaning of a term is a value in the CPO , where contains at all continuous functions from to and an error element W, usually pronounced \wrong". Depending on the concrete type system used, might contain other elements as well. That is, we only assume that satisifes the inequation W + . The meaning function on terms is the same as in the original semantics of Hindley/Milner terms. That is,
62
j
2
2
V
`
V
C
V
?
2 V ! V j
f
`
De nition 10 A constraint system is sound if for all
V
We let range over monotypes.
V
f
8
;
V
0
)
8
De nition 9 A monotype is a type with fv( ) = .
V
0
6
Unlike in the treatment of [Mil78], a denotation of a type scheme in HM(X) can contain the error element W. This is the case when the constraint C in a type scheme :C is unsati able. In this case, the denotation of :C is an empty intersection, that is, all of . However, we will show that none of the type schemes arising in a type derivation of a judgment C; ? e : with a satis able nal constraint C and a consistent type environment ? can contain the error element W. De nition 11 A closed type environment ? is consistent if for all x : ?, W [ ] . An arbitrary type environment ? is consistent if ? is consistent for all type variable substitutions such that ? is closed. De nition 12 A variable environment models a closed typing environment ?, written = ?, if for all x : ?, (x) [ ] . Theorem 13 (Type Soundness) Let C; ? e : be a valid typing judgment in HM( ), where is a sound constraint system. Let be a substitution such that ? and are closed and such that e C . Let be a variable environment such that = ?. Then (1) [ e] [ ] (2) if ? is consistent then W [ ] .
Now, we give a type soundness theorem based on an ideal semantics [MPS86]. We show that our type system is sound, provided the underlying constraint system is sound. We say a constraint system is sound if every satis able constraint has a monotype solution:
V
0
V
Example 1 The Hindley/Milner system is an instance of our type system. Let `
else W
[ e ] = W then ([[e] ) ([[e ] )
[ let x = e in e ] = [ e ] [x := [ e] ] We will show in the following that the meaning of a well-typed program is always di erent from \wrong". As a rst step, we give a meaning to types. Following [Mil78], we let types denote ideals, i.e. downward-closed and limit-closed subsets of . The meaning function [ ] takes closed types and type schemes to an ideals. On function types and type schemes it is de ned as follows: [ 1 2 ] = Tf v [ 1 ] f v [ 2 ] : [ :C ] = [ [= ] ] e [= ]C Lemma 5 Let be a closed type scheme. Then [ ] is an ideal. Proof: A straightforward induction on the structure of .
T
1 = ( ;
2 V ! V ^
C
`
j
V ! V
2
62
5
4.1 Normalization
Proof: A structural induction on typing derivations. There are two interesting cases. Case (Var) Then the last step of the derivation is: C; ? x : (x : ?) Therefore x : ?. Since = ?, [ x] = (x) [ ] . Furthermore, since ? is consistent, W [ ] . Case ( Intro) Then the last step of the derivation is: C D; ? e : fv(C ) fv(?) C :D; ? e : :D Let be such that ? and ( :D ) are closed and such that e (C :D). Let be an arbitrary vector of monotypes such that e :( = ) D Since is sound there is at least one such vector . Let = [= ] . Then since fv(C ), (C D) = C D, which expands to C :( = ) D. By assumption this constraint is valid. Furthermore, ? and are both closed. By the induction hypothesis, [ e] [ ] . Since was arbitrary such that e [ = ]( D), T [ [= ]( )]] e [= ]( D) [ e] = [ ( :D )]]: This gives (1). Assume now that ? is consistent. Again by the induction hypothesis, W [ [= ]( )]], for any such that e [= ]( D). Since, furthermore, there is at least one such , W [ ( :D )]]. `
In this section we study normalization of constraints in a term constraint system. Below we give an axiomatic description of normalization. First, we introduce some preliminary de nitions. Preliminaries: Assume U is a nite set of type variables that are of interest in the situation at hand. We need a handle to compare two substitutions. De nition 14 Let , and be substitutions. Then 0 i ( ) U = U. U 0 . Sometimes, we omit We write if : the set U . Note that this makes the \more general" substitution the smaller element in the pre{order U . This choice, which reverses the usual convention in treatments of uni cation (e.g. [LMM87]), was made to stay in line with the semantic notion of type instances. We make U a partial order by identifying substitutions that are equal up to variable renaming, or equivalently, by de ning =U i U and U . It follows from [LMM87] that U is a complete lower semi{lattice where least upper bounds, if they exist, correspond to uni cations and greatest lower bounds correspond to anti{uni cations. We consider now the task of normalization. Actually, a typing problem is translated in a constraint in the term constraint system X attached with a substitution. Normalization means then computation of a principal normal form of a constraint D from a term constraint system and a substitution . De nition 15 (Principal Normal Form) Let X be a term constraint system over a term algebra and be the set of solved constraints in X. Let C and D X be constraints and let , be substitutions. Then (C; ) is a normal form of (D; ) i , C e D and C = C (C; ) is principal if for all normal forms (C ; ) of (D; ) we have that and C e C . Principal normal forms are unique up to variable renaming: Lemma 6 (Uniqueness) Let (C; ) and (C ; ) be principal normal forms of (D; ). Then there is a variable renaming such that C = C and = . That means computation of the principal normal form of (D; ) is unique. Given (D; ) we can de ne a function normalize by: normalize(D; ) = (C; ) if (C; ) principal normal form of (D; ) = fail otherwise
2
2
j
2
62
8
^
`
62
^ 9
`
8
)
^9
`
9
^
^
0
0
62
0
^
^ 9
j
8
`
g
)
62
`
62
8
)
As a corollary, we get that Milner's slogan \well types programs do not go wrong" carries over to sound constraint extensions. Corollary 1 Let be a sound constraint system. Let true; ? e : be a valid closed typing judgment in HM( ). If = ? then [ e] = W. Proof: Immediate from (1) and (2) of Theorem 13.
T
2 S
2
`
j
S
C
C
0
f
9
j
0
`
2
j
^
0
2
C
0
0
)
8
`
0
[
6
`
0
0
4 Type inference
0
`
0
Type inference in HM(X) is performed in two steps. First, a typing problem is translated into a constraint D in the term constraint system X . Then the constraint D is normalized. Normalizing means computing a substitution and a residual constraint C in X such that C entails D where C is a constraint in the set of constraints in solved form. To ensure that a typing problem has a most general solution, we require that constraints in X have most general normalizers.
0
S
6
0
0
0
0
0
0
0
e
(Ref)
`
^
8
(
)
8
0
i
`
) C D
(
`
i
( = )
62 tv() [ tv(C ) i C ` 8 :D ) 0
0
C `i [ = ] C `e [ = ]D i C ` 8 :D ) 0
0
Figure 2: Instance rules In the latter, we use the convention that when we say the principal normal form of (D; ) exists we imply that there is a procedure which computes the principal normal form of (D; ). Actually, a constraint problem consists of a constraint attached with a substitution. Sometimes, it is more convenient to think of a constraint problem simply as a constraint. Both views are consistent if we want to compute the principal normal form of a constraint problem.
Lemma 7 Given a constraint D
This is easy to see. Assume rst that 1 and 2 are uni able and let = mgu( 1 ; 2 ). Then true
`
e
(
)( 1 = 2 )
and (true; ) is minimal because is a most general uni er of ( 1 ; 2 ). On the other hand, if there is no solution to ( 1 = 2 ), no uni er exists at all. That means, normalization fails.
4.2 The instance relation
X and a substitution . Then (C; ) = normalize( D; id) i (C; ) = normalize(D; ) where C 2 S and a substitution. 2
In order to state the main results we need a handle to compare two type schemes and with respect to a constraint C . This relation is expressed by the term C i , see Figure 2. It is possible to enforce that all ( ) steps are performed before ( ) steps. We simply have the following new relation i2 . All instance rules are the same except for the ( ) rule: 0
We now extend the property of having a principal normal form to constraint systems.
`
0
8
De nition 16 (Principal Constraint Property)
8 `
Given a term constraint system X over a term algebra T and a set of solved constraints S in X. The term constraint system X has the principal constraint property if for every constraint D 2 X and substitution , either (D; ) does not have a normal form or (D; ) has a principal normal form.
8
(
2)
8
C `e [ = ]D C `i2 [ = ] : C `i2 8 :D ) 0
0
and i2 are equivalent. Lemma 8 (Equivalence) Let C be a constraint and ; be type schemes. Then C i i C i2 . Also, the (Ref-), (Weaken) and (Trans) rule are derivable. Lemma 9 The following inference rules are derivable from those in Figure 2. (Ref-) C i D eC C i (Weaken) i The next lemma states that
We also say that the HM(X) type system has the principal constraint property if X has the principal constraint property. Furthermore, we can conclude that every term constraint system X which enjoys the principal constraint property de nes a computable function normalize. In case of the Hindley/Milner type system (or HM(1) in terms of our notation), normalization means simply computation of the most general uni er. We have in this case: normalize(( 1 = 2 ); ) = (true; mgu( 1 ; 2 ) ) if 1 ; 2 are uni able = fail otherwise
`
i
0
`
`
`
`
(Trans)
7
`
`
C
i `
0
D ` 1 2 C `i 2 3 C `i 1 3 0
0
0
The output of a typing problem is a triple consisting of a type scheme , a substitution, and a constraint C . We call such a triple a typing con guration. De nition 17 Given a constraint C and a type environment ?. Then a substitution is called consistent with respect to C and ? i C and for each x : :D ? the constraint D is in where we assume that there are no name clashes between and . W.l.o.g. we can assume that each type scheme is of the form :D . De nition 18 (Typing Con gurations) Given a type environment ?, a constraint C , a type scheme and a substitution such that C = C , = and is consistent in ?. Then (C; ; ) is a typing con guration with respect to ?. For simplicity, we omit sometimes the phrase \with respect to ?". Given typing con gurations (C; ; ), (C ; ; ) and a type environment ?. Then (C; ; ) is more0 gen eral than (C ; ; ) with respect to ? i fv(?) , e i C C and C . We write (C; ; ) ? (C ; ; ). The next lemma expresses the relationship between typing judgments and con gurations. Lemma 10 Let (C; ; ) and (C ; ; ) be typing con gurations where (C; ; ) ? (C ; ; ), ? be a type environment and C; ? e : be a typing judgment. Then we can derive the typing judgment C ; ? e : .
are combined. This step is trivial in case of the (Abs) rule. The (Var) rule represents the base case. An initial result is generated. In case of the (App) a uni cation problem is added to the combined constraints. In all cases, we get a tuple consisting of a constraint and a substitution. A normalization step is performed which results in a tuple consisting of a constraint in solved form and a substitution. This normalization is not necessary in case of the (Abs) rule. As a result, the algorithm reports a triple consisting of a constraint, a type and a substitution. We can state that the result triple of the type inference algorithm W always forms a typing con guration.
2 S
8
)
2
8
S
)
`
2 S
0
0
0
`
0
0
0
0
0
Lemma 11 Given a type environment ? and a term e.
If ; C; ? tion.
`
0
0
0
0
environment ?. If ; C; ? , C = C and = .
0
0
`
4.3 Type inference algorithm
We now give a generic type inference algorithm for a HM(X) type system. The algorithm can be found in Figure 3. The following de nition is a generalization of the ( Intro) rule. De nition 19 Let C be a constraint, ? be a type environment, be a type scheme and = (fv() fv(C )) fv(?). Then gen(C; ?; ) = ( :C; :C ). In the algorithm we treat a type as :true where fv( ) to avoid a special treatment of types in the (Var) rule. The algorithm is formulated as a deduction system over clauses of the form ; C; ? W e : with type environment ?, expression e as input values and substitution , constraint C , type as output values. For each syntactic construct of expressions e we have one clause. In an operational reading of the type inference algorithm, it constructs a bottom{up derivation of W clauses. Type inference in HM(X) is performed in two steps. First, the results of the typing problems of the premises 8
[
9
8
n
)
8
W
e:
then C; ?
`
e:
`
`
0
`
To obtain a completeness result for type inference, we assume that we have an HM(X) type system which ful lls the principal constraint property. Furthermore, we consider only those typing judgments C; ? e : where the type environment and the constraint on the left hand side of the turnstyle are realizable, i.e. have a type instance.
0
0
e : then (C; ; ) is a typing con gura-
Theorem 20 (Soundness) Given a term e and a type
0
0
W
Furthermore, this typing con guration always represents a vaild typing of the given term under the given type environment.
0
0
`
)
62
`
`
8
De nition 21 Let C be a constraint and ? be a type 0
0
environment. Then ? is realizable in C i for every i ` . 0
0
x : 2 ? there is a such that C 0
0
Now, we present our completeness result. Informally speaking, we want to have the following. Given a derivation C ; ? e : , our type inference algorithm should report a constraint that is at least as small as C and a type that is at least as general as . 0
`
0
0
0
Theorem 22 (Completeness) Let C ; ? 0
`
e : be 0
a typing judgment and ? is realizable in C . Then 0
; C; ? `W e :
for some substitution , constraint C , type , such that gen(C; ?; ) = (Co ; o ) (Co ; o ; ) ? (C ; ; ) 0
0
x : (8 :D ) ) 2 ? new ]) (C; ) = normalize(D; [ = W fv(?) ; C; ? ` x :
(Var)
j
; C; ?x :x : `W e : new W ; C; ?x ` x:e : !
(Abs)
nf
1 ; C1 ; ?
(App)
D
g
W
2 ; C2 ; ? 0 = 1t 2 = C1 ^ C1 ^ ( 1 = 2 ! ) `
e1 : 1
`
W
e2 : 2
new
(C; ) = normalize(D; ) W e1 e2 : fv(?) ; C; ? 0
`
j
1 ; C1 ; ? x
W
e: (C2 ; ) = gen(C1 ; 1 ?; ) W 2 ; C3 ; ?x :x : ` e : = 1 t 2 D = C 2 ^ C3 (C; ) = normalize(D; ) W fv(?x ) ; C; ?x ` let x = e in e : `
0
(Let)
0
0
0
0
j
0
Figure 3: Type inference Let us brie y comment the completeness result. We assume that we have a typing con guration (C ; ; ) such that C ; ? e : . Then if we generalize the results of the type inference algorithm, we get a more general typing con guration. A sketch of the proofs of soundness and completeness of type inference can be found in the appendix. For a more detailed discussion we refer to [Sul97b]. The completeness theorem can be simpli ed for top{ level programs to the following corollary, which states that our type inference algorithm computes principal types. 0
0
But it is possible to generate all constraint problems rst and perform normalization only right before we reach a (Let) clause or the root clause. The following lemma states that we can delay normalization and perform normalization in any order and we always get the same result. Lemma 12 Given constraints D1; D2 in X and substitutions 1 ; 2 . Then the principal normal form of (D1 D2 ; 1 2 ) exists i the principal normal form of (C1 D2 ; 1 2 ) exists with (C1 ; 1 ) principal normal form of (D1 ; 1 ) i the principal normal form of (C1 C2 ; 1 2 ) exists with (C2 ; 2 ) principal normal form of (D2 ; 2 ) . Especially,
0
0
`
Corollary 2 (Principal Types) Let true; ?
`
^
^
e:
be a closed typing judgment such that ? is realizable in true. Then ; C; ? `W e : for some substitution , constraint C , such that i
o
t
t
normalize(D1 ^ D2 ; 1 t 2 ) = normalize(C1 ^ D2 ; 1 t 2 ) = normalize(C1 ^ C2 ; 1 t 2 )
gen(C; ?; ) = (true; o ) `
t
^
where
Our type inference algorithm interleaves constraint generation and normalization. Each inference rule combines the constraint problems of the premises and performs then a normalization step. This treatment is due to the (Let) rule. We only admit constraints in solved form in a type scheme. Therefore, we have to perform normalization before we do generalization of a type.
normalize(D1 ; 1 ) = (C1 ; 1 ) normalize(D2 ; 2 ) = (C2 ; 2 )
Hence, if our type inference algorithm only applies clauses (Var), (Equ), (Abs) and (App) it is equivalent to accumulate all typing problems rst and perform normalization at the end. This can be proven by a simple 9
induction on the number of inference steps and with the help of Lemma 12.
R1 e ( l1 : 1 ; : : : ln : n ::< li : i >) where l1 ; : : : ; ln are distinct R2 ( ::< l : 1 >) ( ::< l : 2 >) e ( 1 = 2) R3 ( : : : ; l : 1 ; : : : ::< l : 2 >) e ( 1 = 2) R4 ( l1 : 1 ; : : : ; ln : n ::< l : >) e false where l is distinct from l1 ; : : : ; ln R5 ( 1 2 ::< l : 3 >) e false E5 :( :: k) =e true where fv(k) E6 :( :: k) =e false where fv(k) F1 false e P for P
F2 :false =e false Remark 4 Conditions R1 { R5 are a straightforward extension to constraints on records. Conditions E5 { E6 de ne how projection operates on record constraints. E5 and E6 express the fact that no recursive records are `
5 A record application HM(R)
^
2
`
2
9
R
allowed. A token false is used. It represents the false element of the constraint system. An axiomatization is given in F1 and F2. The token false is assumed to be contained in the set of primitive constraints. It is also important to point out that we only have width subtyping because we do not have the subsumption rule in the HM(X) type system. Furthermore, we also forbid overloading of eld labels. This is along the lines as in [Oho95]. It remains to de ne the set S of constraints in solved form. First, we require that all constraints (::) in S are of the form ( :: ). We put additionally the following condition on S : S5 If C 2 S then there is an ordering < on the type variables in C such that for all predicates ( ::< l : >) and 2 fv( ) with C `e ( ::< l : >) we have that < Then we de ne S as the greatest set of constraints which ful lls conditions S1 { S5. Remark 5 Condition S5 simply states that no recursive records are allowed in HM(R). Recursive records are also not allowed in [Oho95]. We now add primitive constructs to the initial type environment ?0 that deal with record formation, selection and update. For every constructor l1 : : : ln we have a datatype constructor l1 : : : ln : 1 ! : : : ! n ! fl1 : 1 ; : : : ; ln : n g in the initial type environment ?0 . l1 : : : ln allows us formation of records fl1 : 1 ; : : : ; ln : n g. For each eld label l we add .l : 8 ; :( ::< l : >) ) !
g
T
l1 : : : ln : 1 ! : : : ! n ! fl1 : 1 ; : : : ; ln : n g
to the signature . We assume that the order of the elds does not matter. Additionally, we require ( l1 : 1 ; : : : ; ln : n = l(1) : (1) ; : : : ; l(n) : (n) ) where is a permutation on 1; : : : ; n g
g
f
`
62
R
f
`
9
O
f
g
9
R
e
`
!
R
f
`
g
f
T C ST
`
g
f
Following ideas of Ohori [Oho95] we give an instance of our HM(X) system which deals with polymorphic records. First, we give an instance of a term constraint system . It must now be able to deal with constraints on records. We also add primitive operations to the initial type environment ?0 that deal with record selection and record update. Furthermore, we discuss the relationship of HM( ) to Ohori's calculus (In the latter we use as an abbreviation for Ohori's calculus). Finally, we show that enjoys the principal constraint property. That means, we get a type inference algorithm for HM( ) which computes principal types. In addition to types and function types we have now record types denoted by l1 : 1 ; : : : ; ln : n where li is an element of a enumerable set of record labels. We extend the term algebra by adding constructors
D7
f
g
Note, here you can see an example for a type constructor with non{trivial equality relation. In [Oho95] kinded types are introduced. < l : > is a record kind intuitively denoting all records which contain at least a eld label l with value . Constraints on record types are now expressed by kinded types. That means in our constraint language we have now constraints of the form ( :: k) where is a type and k is a kind. Technically, this means we add ( :: k) to the set of primitive constraints where (::) is a primitive predicate of arity 2. Also, we require for the term constraint system the following additional rules: R
10
Example 3
and
f: 8 :9 :( ::< l1 : >) ^ ( ::< l2 : >) ) ! Int fx= let g: 8 :( ::< l1 : >) ^ ( ::< l2 : >) ) ! Int g = y. (x.l1 , (x.l1 ).l2 , eq y (x.l1 )) in 1
modifyl : 8 ; :( ::< l : >) ) ! !
to the initial type environment ?0 . The rst corresponds to record selection, the latter to record update. The question arises how HM( ) is related to . In HM( ) we have the same basic operations as in . But our constraint system di ers in two respects from the one used in . We have an equality predicate (=) and a projection operator . The equality predicate becomes important when we consider type inference which we will do in the latter. We have already pointed out that the projection operator allows us to formulate a logically pleasing ( Intro) rule. Essentially, the only di erence between HM( ) and lies in the introduction of quanti ed type variables. In we have the following ( Intro) rule: R
O
R
That means, HM( ) can be seen as the proper logical formulation of . Especially, we get that HM( ) models faithful. Theorem 23 Every program typable in is also typable in HM( ). But we can type programs in HM( ) which are not typable in . In the above example we can apply f to an appropriate argument which is not possible in . In Section 9 we discuss some more examples for di erent formulations of the ( Intro) rule and problems which then arise. We now consider type inference for HM( ). That means we have to show that ful lls the principal constraint property. We have already mentioned that our constraint system di ers from the one used in . We have an equality predicate (=) and a projection operator . We do the following steps to prove that the principal constraint property holds for . We show that it is always possible to split a constraint in a projection free subpart. Then we give a procedure which computes the principal normal form of projection free constraints, or no normal form exists at all. Finally, we show that it is sucient to compute principal normal forms of projection free constraints. We now want to split a constraint into a projection free subpart. The idea is that we can always rename type variables which are bound by the projcetion operator. It holds that
O
R
O
O
9
O
R
R
8
R
O
O
O
O
8
( Intro- ) 8
O
8
7! kg; ? ` e : 62 fv(?) K ; ? ` e : 8 :( :: k ) )
Kf
R
R
Ohori uses instead of a constraint on the left hand side of a typing judgment a so-called kind assignment which can be considered as a function from type variables to kinds. He writes k for the disjoint extension of with a new type variable with kind k. We can now write the following program in where we assume that we have a funciton eq : : Bool in an initial type environment and an operator ( ; ; ) for formation of triples. We use a Haskell-style notation, adding type annotations for illustration purposes.
O
K
Kf
7!
9
g
R
K
O
8
!
R
O
!
Example 2 f: 8 :( ::< l1 : >) ) ! Int fx= let g: 8 :( ::< l2 : >) ) ! Int g = y. (x.l1 , (x.l1 ).l2 , eq y (x.l1 )) in 1
:C =e 9 :[ = ]C
9
where is a new type variable. That means, w.l.o.g. there are no name clashes between two projected constraints ( :C ) ( :D) Then we can use condition E3 to shift all projection operators to the outermost level. We can summarize this observation in the following lemma.
The type of f looks strange. The function f is closed but the type of f contains the free type variable . We can not quantify at the outermost level otherwise we would get a con ict with the conditions put on a kind assignment. Furthermore, should be a record type but there is no such restriction put on . Actually, this program is non{sensical. We can type f but we can not apply f to an argument. The reason is that does not appear anymore in the kind assignment . And this means we can not nd an instance for the constraint in f's type. In HM( ) we can type f in the following way.
9
^
9
Lemma 13 Let C
2 R. Then there exists a projection free constraint D such that C =e 9 :D .
We assume now that we have a projection free constraint D which contains only primitive predicates of the form (=) and (::). Furthermore, we can assume
K
R
11
Lemma 16 Let D
that all predicates (::) are of the form ( :: k) because we know that
2 R and be a substitution where codom( ) [ dom( ). If (C; ) = normalize(D; ) then (9 :C; ) = normalize(9 :D; ). The next lemma states that a normal form of a constraint exists if a normal form of the projected constraint exist. Lemma 17 Given a substitution where 62 codom( )[ dom( ) and a constraint D 2 R. Then (D; ) has a normal form if (9 :D; ) has a normal form. We have now everything at hand to prove that R has the principal constraint property. Theorem 24 The constraint system R has the principal constraint property. Proof: Assume the contrary. That means we have a tuple (D; ) which has a normal form but no principal normal form. With Lemma 13 we know that D =e 9 :D where D is a projection free constraint. Then we apply Lemma 17 and get that the normal form of (D ; ) exists. From Lemma 15 we know that (D ; ) does have a principal normal form. With Lemma 16 we can lift the principal normal form and get that the principal normal form of (D; ) exists. But this is a contradiction to our assumption. We get that R has the principal constraint property.
( :: k) =e :( = ) ( :: k) 9
nf
^
where is a new type variable. The closure Cl(D) of D is the smallest constraint which ful lls the following conditions: 1. D Cl(D) 2. If ( = l1 : 1 ; : : : ; ln : n ) Cl(D) then ( ::< l1 : 1 >); : : : ; ( ::< ln : n >) Cl(D) 3. If ( ::< l : 1 >); ( ::< l : 2 >) Cl(D) then ( 1 = 2 ) Cl(D)
f
g
2
2
2
2
From a semantic view point we have not done anything because Cl(D) =e D. We simply have changed the syntactic representation of D. The intention of building the closure of D is simply to generate all predicates ( ::< l : >) which might cause any inconsistencies. From that we can generate all uni cation problems ( = ) which have to be resolved. The following lemma states that we really have generated all such predicates. 0
0
0
Lemma 14 Given a eld label l and types 0
0
0
0
0
0
g
0
0
; . If ::< l : >) then ( ::< l : >) 2 Cl(D) i ( ::< l : >). Furthermore, if 6 `e ( = ) then ( = ) 2 Cl(D) i D `e ( = ). e 6 ` ( D `e
62
0
0
That means, we know that the constraint system has the principal constraint property and we have a decidable procedure at hand to compute the principal normal form. We have given an instance HM( ) of our HM(X) system which deals with records. We extended the term algebra and had to provide a constraint system which is able to deal with records. We showed that satis es the principal constraint property. We omit the discussion of further extensions like record extension or recursive records. In [Sul97a] we discuss an instance of our HM(X) framework that deals with recursive records, extension and concatenation of records. We believe that this instance provides a good wrapper for object calculi. R
Then we can apply uni cation over Herbrand terms [Rob65]. to resolve all equality predicates (=) in Cl(D). Actually, that is not the whole truth. Remember, we have a record type constructor with non{trivial equality relation in the term algebra . That means, when we perform uni cation we have to take into account that records are equal modulo up to the order of the elds. We get a most general uni er of the equality predicates (=) in Cl(D). It remains to check whether this most general uni er is consistent with Cl(D). That means, we check whether there are any inconsistencies in Cl(D). If not, ( Cl(D); ) represents the principal normal form of (D; id). We can summarize this observation in the following lemma.
R
T
T
R
R
Lemma 15 Given a projection free constraint D 2 R and a substitution . Then (D; ) does have a principal normal form or no normal form exists.
6 Getting a HM(X) instance for free Whenever we want to design a new instance of our HM(X) framework we have to give a term constraint system which enjoys the principal constraint property. Very often we can rely on already existing approaches which also use a kind of constraint system and a procedure to normalize constraints. For example Ohori[Oho95] introduced a constraint system where types were associated with kinds. His normalization procedure is a
We have given now a procedure to compute the principal normal form of projection free constraints. The next lemma gives us a procedure to lift principal normal forms of constraints to arbitrary constraints. It states that whenever we can compute the principal normal form of a constraint D then we get the principal normal form of the constraint :D for free. 9
12
form of kinded uni cation. The main di erence between such approaches and ours is that we have a projection operator. It would be a nice property if we could lift already existing constraint systems and normalization procedures to get an instance of our HM(X) system. For instance, in case of HM( ) we adapted an already existing constraint system. We added rules how projection operates on constraints. Then, we gave a procedure which computes the principal normal form of projection free constraint. Finally, we showed how to lift this procedure to arbitrary constraints. It is possible to generalize this result for a speci c class of constraint systems.
The set of solved constraints in is equal to the set of satis able constraints in . Now, we introduce an extension SHM(X) of the Hindley/Milner system with a subtype constraint system X over a term algebra . The subsumption rule is added to the logical type system in Figure 1: S
T
R
De nition 25 Given a term constraint system
The relation
T
T
(
)
C `s [ = ] C `e [ = ]D C `s 8 :D )
0
0
0
SC
)
S2
D `e ( 1 1 ) D `e ( 2 2 ) D `e ( 1 ! 2 1 ! 2 )
S3
D `e ( 1 2 ) D `e ( 2 3 ) D `e ( 1 3 )
0
0
0
0
!
0
!
`
0
8
T
0
As for i , we get that the (Re -), (Weaken) and (Trans) rules hold. That means, Lemma 9 holds also in this case. Additionally, we have the ( Intro) rule. Lemma 18 ( Intro) Let C be a constraint and 1 ; 2; 3 be types. If C s 1 1 and C s 2 2 then C s 1 2 1 2 . It is interesting to point out that rules ( Elim) and (Equ) are now entailed in the (Sub) rule. We can leave them out from the typing rules for SHM(X) type systems. In this case, computation of the principal normal form represents simply a satis ability test. We get that: normalize(D; ) = ( D; ) if D satis able = fail otherwise We can show that for all subtype constraint systems X the test whether a constraint is satis able or not is decidable. We adopt the approach by Aiken/Wimmers [AW93]. They use an ideal model [MPS86] to show that each type variable of a satis able constraint can be assigned to an ideal in the ideal model. It is decidable to test whether each type variable in a constraint has a solution in the ideal model. It is important to note that we are not interested in the best solution. We only need a decidable satis ability test. In case of simpli cation, nding the best solutions becomes an important issue. We can conclude that the principal constraint property holds for SHM(X) type systems. The type inference algorithm for SHM(X) type systems is the same except for the (App) rule. Instead `
type constraint system over a term algebra is a term constraint system with the following additional properties. For each pair of types and there is a subtype predicate ( ) in , which satis es: 0
0
`
De nition 27 (Subtype Constraint System) A sub-
0
0
!
We now consider an extension SHM(X) of our HM(X) framework that deals with subtypes. We enrich the constraint system X with subtype constraints and we add the subsumption rule to the logical type system. First, we introduce a constraint system that is able to express subtyping.
) ^ (
0
!
7 An extension SHM(X) with subtypes
)
`
T
0
C `e ( C `s
C ^ D `s 62 tv() [ tv(C ) C `s 8 :D )
8
T
S1 ( = ) =e (
obeys the following rules:
)
8
Theorem 26 (Lifting) Let T C S be a term constraint system, such that the lifting condition holds Then T C S has the principal constraint property.
s
(
T
0
`
e : C `s C; ? ` e :
`
(Entail)
T
SC
C; ?
(Sub)
T CS . We say that T C S satis es the lifting conditions i the following conditions hold:
(L1) Every D 2 T C S has a normal form as described in Lemma 13 (L2) Every projection free constraint D 2 T C S has a principal normal form (L3) If 9 :D 2 S and D 62 S then there exists a such that, e [ = ]D 9 :D =
SC
SC
0
13
0
Lemma 19 Let C; ?
of the equality predicate (=) we have now the subtype predicate ( ):
` e : be a typing judgment and 62 fv(?) [ fv(). Then 9 :C; ? ` e : .
(App)
D
`
W
Based on the above lemma we are able to state the following simpli cation rule:
W 2 ; C 2 ; ? ` e2 : 2 0 = 1t 2 = C1 ^ C1 ^ ( 1 2 ! ) new
1 ; C1 ; ?
e1 : 1
0
`
j
`
e: 62 fv(?) [ fv() 9 :C; ? ` e :
Pottier [Pot96] and the Hopkins Object Group [EST95a] developed independently methods to remove unreachable constraints. The (Simp) rule gives a semantic justi cation for doing so. They also examine some other simpli cation techniques: Replacing a variable with its bound: For instance, if a type variable occurs only positively in a type, we can replace this type variable with its lower bound. Merging of variables: We consider now subtyping. If we have a typing judgment C; ? e : and the cyclic constraint ( ) ( ) is entailed by C and furthermore is not free in ? then we can substitute with . All of these techniques involve computation of a substitution. This substitution is applied to the given typing judgment. We can state the following substitution rule which follows immediately from Lemma 10:
Example 4
id; ( ! ) ^ ( ! ); ; W
`
f:x:f (fx) : ! ! :
Related Work:
`
SHM(X) is most closely related to the approach of the Hopkins Object Group [EST95b]. But instead of simply duplicating the constraint in the ( Intro) rule we split it up into two versions, one existentially quanti ed the other universally quanti ed. Consider the constraint C = ( ) ( ): If we quantify the type variable we get the constraint :C which can safely be simpli ed to ( ) since the denotation is the same for both constraints. The type inference algorithm of the Hopkins Object Group keeps the constraint C . That means their type inference algorithm ends up in a large constraint set whereas our framework gives a semantic basis for simpli cations by the projection operator.
^
0
^
0
0
8
9
C; ?
(Simp)
(C; ) = normalize(D; ) W e1 e2 : fv(?) ; C; ? We get the same results as already stated in Section 4. Furthermore, we get that type inference always reports the id substitution. That is true for the (Var) rule. And whenever we have to compute a normalization we know that normalize(D; id) = (D; id). Therefore, the other inference rules report also the id substitution. Consider the following example.
(Subst)
0
e:
0
C
C `i
fv(?) = id C `e C C `i C; ? ` e : C; ?
`
0
j
We need the conditions fv(?) = id C 0
j
`
e
to ensure that application of the (Subst) rule is complete. That means the typing judgment of the conclusion should be as least as general as the typing judgment of the premise. Our framework thus supports a semantic basis for simpli cations. Our semantic de nition of constraint systems allows us to change the syntactic representation of a constraint without changing its denotation. Existing simpli cation techniques [Pot96, EST95a] can be integrated into our framework as was sketched above.
8 Simpli cation A current trend in research for type inference with constrained types is to simplify constraints, see [Pot96, EST95a]. Simpli cation deals with the problem that type inference introduces many intermediate variables which make constraints large and hard to understand for the programmer. Simpli cation hides these intermediate variables. This corresponds exactly to the role of projection in our framework. The following lemma expresses under which circumstances we can bind type variables by the projection operator, that means making them invisible to the programmer.
9 Related work All constrained type systems we study extend the type judgements ? e : of the Hindley/Milner system `
14
with a constraint hypothesis on the left hand side of the turnstyle, written C; ? e : . Furthermore, they extend the type schemes : of the Hindley/Milner system with a constraint component; we write :C to express that the constraint C restricts the types that can legally be substituted for the bound variables . All type systems have essentially the same rule for eliminating quanti ers, which we write as follows: C e [ = ]D ( Elim) C; ? e : D: C; ? [ = ] The rule is a re nement of the corresponding rule in the Hindley/Milner system. It says that, when instantiating a type scheme :D , the only valid instances are those instances [ = ] which satisfy the constraint part D of the type scheme. While there is agreement about the proper technique for eliminating quanti ers in type schemes, there is remarkable disagreement about the proper way to introduce them. Figure 4 shows four di erent rules that have all been proposed in the literature. We have edited these rules somewhat to present them in a uniform style, and have attempted to compensate for the considerable variations in detail between published type systems. Even though these details matter for each particular type system, we have to abstract here from them in order to concentrate on general principles. We now discuss each of the four schemes in turn. In his work in quali ed types [Jon92], Jones uses a general framework for type quali cation with a rule equivalent to rule ( Intro-1). Any constraint can be shifted from the assumption on the left to the type scheme on the right of the turnstyle; it is not checked if the constraint so traded is satis able or not. This might lead to programs that are well-typed as a whole, even though some parts have unsatis able constraints. To give an example, assume that our constraints are subtyping constraints ( ) in a type system with records. Let us assume that there is a parametrized type List with a less eld such that for all types , List less : List Bool : Let us further assume that there is a value Nil of type :true List that represents the empty list. Consider the following (nonsensical) program.
We use a Haskell-style notation, adding type annotations for illustration purposes. Using rule ( Intro-1), the program in 5 is well-typed, even though we would not expect the constraint in function f's type scheme to have a solution, since the function type List would not have a less eld of type Bool Bool. In the ideal semantics of types [MPS86], which represents universal quanti cation by intersection, f 's type would be an empty intersection, which is equal the whole type universe including the error element wrong. However, the whole program in 5 is still sound because every application of f must provide a valid instantiation of the constraint. Since the constraint is unsatis able, no application is possible. In essence, Jones treats constraints as proof obligations that have to be ful lled by presenting \evidence" at the instantiation site. This scheme is clearly inspired by Haskell's implementation of overloading by dictionary passing. It runs into problems if one ever wants to compute a value of a constrained type without any instantiation sites, as in the following slight variation of Example 5.
`
8
8
8
`
8
)
8
)
0
`
0
`
8
!
0
)
0
8
f
8
!
g
)
Example 5
let f: 8 :(List fless : Bool ! Boolg) ) List ! f x = if x.less(true) then x else Nil in 1 end
Example 6 let
y: 8 :(List fless : Bool ! Boolg) ) Bool y = Nil.less(true) in 1 end Jones excludes this code on the grounds that y's type
is ambiguous, but it is unclear how to generalize this restriction to arbitrary constraint systems. Nevertheless, it might be possible to integrate Jones' approach into our HM(X) framework, thus giving it a semantic basis independent of dictionary passing. The essential idea is that we have to restrict ourselves to constraint systems in which projections of solved constraints are trivial, i.e e :C , for all constraints C , type variables fv(C ). The term constraint system on the other hand, can have non{trivial projections. In this case, our rule ( Intro) simpli es to ( Intro-1). Note, that trivial projections correspond well to Haskell's \open world" assumption, which says that the range of possible instance types for an overloaded operation is not xed in advance. Therefore, we can never rule out that a given constraint which still has free variables might have a solution. A formalization of this principle using a \bottom type" [OWW95] makes it possible to de ne a compositional semantics for Haskell{style overList loading. In the type system of Aiken/Wimmers [AW93], moving a constraint from the left hand side of the turnstyle to the right-hand side is allowed only if the constraint is `
S
9
2
2
T C ST
8
8
15
No satis ability check[Jon92]:
C ^ D; ? ` e : 62 fv(C ) [ fv(?) C; ? ` e : 8 :D )
Weak satis ability check[AW93]:
C ^ D; ?
Strong satis ability check[Smi91]:
C ^ D; ?
Duplication[EST95b]:
C ^ D; ? ` e : 62 fv(C ) [ fv(?) C ^ D; ? ` e : 8 :D )
`
`
e: C; ? e:
( Intro-1) 8
62 fv(C ) [ fv(?) e : 8 :D ) D
( Intro-2)
9
`
C
C; ?
`
[ = ]D e : :D
`
8
)
8
62 fv(C ) [ fv(?)
( Intro-3) 8
( Intro-4) 8
Figure 4: Versions of the quanti er introduction rule satis able (i.e. has a solution). Hence, none of the previous examples would be typable with rule ( Intro-2), which they use. However, this example is typable.
with precisely two instances: Int fless: Int ! Boolg Char fless: Char ! Boolg
8
Example 7
Now consider the following program:
let
Example 8
f: 8 : ! Int fx= let y: 8 :(List fless : ! Boolg) ) Bool y = Nil.less(x) in 1 in f true The constraint List fless : ! Boolg has a solution, namely = List . Therefore, using rule (8 Intro-2) we can generalize y's type to
let
f: 8 : ! Int fx= let g y = y.less(x) in 1 in 1
When typing the de nition of g, Smith's system requires a solution of the constraint Less; , where is y's type. Two solutions exist: = Int or = Char, there is no best type for y that improves on both solutions. The system of the Hopkins Objects Group [EST95b] di ers from the previous three systems in that in rule ( Intro-4) the constraint D is copied instead of moved; there are no restrictions on when the copying can take place. Under this scheme, the rst three examples would be rejected and the fourth one would be accepted, which corresponds fairly well to our intuition. At the same time, rule ( Intro-4) seems strange in that its conclusion contains two copies of the constraint D, one in which the type variables are bound and one in which they are free. Actually, the Hopkins Objects Group use a slightly di erent system in which generalization is coupled with the let rule and one of the two constraints undergoes a variable renaming. HM(X) can be seen as the proper logical formulation of their more algorithmically{formulated type system. Furthermore, instead of dealing exclusively with subtype constraints, we admit arbitrary constraint systems. Finally, we have
:(List fless : ! Boolg):Bool:
8
On the other hand, if we substitute the actual parameter true in f's de nition, we get again Example 6 which is not typable under the system with ( Intro-2). Hence, the system with ( Intro-2) does not enjoy the property of subject reduction, which says that if a term is typable then its reduction instances are typable as well. In a later version, they use rule ( Intro-4) instead. Where Aiken and Wimmers require only a weak form of satis ability for traded constraints, G. Smith requires a strong one [Smi91]. In rule ( Intro-3), the traded constraint D must be solvable by instantiation of only the quanti ed variables . Hence, all three previous examples would be untypable under his system. However, ( Intro-3) rule seem overly restrictive, depending on the constraint system used. In a type system in which subtyping is by declaration, assume we have a record type 8
8
8
8
8
8
8
type Less a = fless: a!Boolg
16
already seen that our use of projection gives a semantic justi cation to the simpli cation techniques they study [EST95a].
[CCH+ 89] Peter Canning, William Cook, Walter Hill, Walter Oltho , and John C. Mitchell. Fbounded polymorphism for object-oriented programming. In Functional Programming Languages and Computer Architecture, pages 273{280, September 1989. [CHO92] Kung Chen, Paul Hudak, and Martin Odersky. Parametric type classes. In Proc. of Lisp and F.P., pages 170{191. ACM Press, June 1992. [CW85] Luca Cardelli and Peter Wegner. On understanding types, data abstraction, and polymorphism. Computing Surveys, 17(4):471{ 522, December 1985. [DHM95] Dirk Dussart, Fritz Henglein, and Christian Mossin. Polymorphic binding-time analysis in polynomial time. In Proceedings of SAS, pages 118{135. Springer Verlag, September 1995. [DM82] Luis Damas and Robin Milner. Principal type schemes for functional programs. January 1982. [EST95a] Jonathan Eifrig, Scott Smith, and Valery Trifonov. Sound polymorphic type inference for objects. In OOPSLA, 1995. [EST95b] Jonathan Eifrig, Scott Smith, and Valery Trifonov. Type inference for recursivly constrainted types and its application to object oriented programming. In Electronic Notes in Theoretical Computer Science, volume 1, 1995. [HMT71] L. Henkin, J.D. Monk, and A. Tarski. Cylindric Algebra. North-Holland Publishing Company, 1971. [JM94] Joxan Ja ar and Michael Maher. Constraint logic programming: A survey. Journal of Logic Programming, 19(20):503{581, 1994. [Jon92] Mark P. Jones. Quali ed Types: Theory and Practice. D.phil. thesis, Oxford University, September 1992. [Jon95] Mark P. Jones. Simplifying and improving quali ed types. In FPCA '95: Conference on Functional Programming Languages and Computer Architecture. ACM Press, 1995. [Kae92] Stefan Kaes. Type inference in the presence of overloading, subtyping, and recursive types. pages 193{204, June 1992.
10 Conclusion We have presented a general framework HM(X) for Hindley/Milner style type systems with constraints. Constraint systems are introduced in terms of cylindric algebras. We have introduced a new formulation of the ( Intro) rule. Also, if the constraint domain X has the principal normal form property we get the principal type property. To design a full language or static analysis based on our approach, one must simply check that the conditions on the constraint system are met. If this is the case, one gets a type inference algorithm and the principal type property for free. We have given an instance of our HM(X) framework that deals with polymorphic records. Based on the record system of Ohori, we have shown how to encode his system in terms of our HM(X) framework. The critical part was to lift existence and computation of kinded uni cation to arbitrary constraints. By the Lifting Theorem 26 it is not dicult to encode also further systems. Furthermore, we discussed an extension SHM(X) of HM(X) where we additionally have subtype constraints. We added the subsumption rule to our logical type system. We could show that the principal constraint property holds in general for SHMX(X) type systems. That means, type inference for SHM(X) type systems always computes principal types. Our HM(X) framework provides a foundation to experiment with new constraint domains in a systematic way. It remains a topic for the future to consider further applications. 8
References [AW93]
Alexander Aiken and Edward L. Wimmers. Type inclusion constraints and type inference. In FPCA '93: Conference on Functional Programming Languages and Computer Architecture, Copenhagen, Denmark, pages 31{41, New York, June 1993. ACM Press. [BSvG95] Kim B. Bruce, Angela Schuet, and Robert van Gent. Polytoil: A type-safe polymorphic object-oriented language (extended abstract). In Procceding of ECOOP, pages 27{ 51. Springer Verlag, 1995. LNCS 952. 17
[LMM87] J. Lassez, M. Maher, and K. Marriott. Uni cation revisited. In J. Minker, editor, Foundations of Deductive Databases and Logic Programming. Morgan Kau man, 1987. [Mil78] Robin Milner. A theory of type polymorphism in programming. Journal of Computer and System Sciences, 17:348{375, Dec 1978. [Mit84] John C. Mitchell. Coercion and type inference. In Proceedings of the 11th ACM Symposium on Principles of Programming Languages, pages 175{185, 1984. [MPS86] D. MacQueen, G. Plotkin, and R. Sethi. An ideal model for recursive polymorphic types. Information and Control, 71:95{130, 1986. [NP93] Tobias Nipkow and Christian Prehofer. Type checking type classes. In Conference Record of the Twentieth Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, Charleston, South Carolina, January 10{ 13, 1993, pages 409{418. ACM Press, January 1993. [Oho95] Atsushi Ohori. A polymorphic record calculus and its compilation. ACM TOPLAS, 6(6):805{843, November 1995. [OWW95] Martin Odersky, Philip Wadler, and Martin Wehr. A second look at overloading. In Proc. ACM Conf. on Functional Programming and Computer Architecture, pages 135{1469, June 1995. [Pal95] Jens Palsberg. Ecient inference of object types. Information and Computation, 123(2):198{209, 1995. [Pot96] Francois Pottier. Simplifying subtyping constraints. In International Conference on Functional Programming, pages 122{133, May 1996. [Rem89] D. Remy. Typechecking records and variants in a natural extension of ML. pages 77{88. ACM, January 1989. [Rem92] Didier Remy. Extending ML type system with a sorted equational theory. Research Report 1766, Institute National de Recherche en Informatique et en Automatique, 1992.
[Rey85]
John C. Reynolds. Three approaches to type structure. In Proceedings TAPSOFT/CAAP 1985, pages 97{ 138. Springer-Verlag, 1985. Lecture Notes in Computer Science 185. [Rob65] J. A. Robinson. A machine-oriented logic based on the resolution principle. Journal of the Association for Computing Machinery, 12:23{41, 1965. [Sar93] Vijay A. Saraswat. Concurrent Constraint Programming. Logic Programming Series, ACM Doctoral Dissertation Award Series. MIT Press, Cambridge, Massachusetts, 1993. [Smi91] Geo rey S. Smith. Polymorphic type inference for languages with overloading and subtyping. PhD thesis, Cornell University, Ithaca, NY, August 1991. [Sul97a] Martin Sulzmann. Designing Record Systems. Research Report YALEU/DCS/RR1128, Yale University, Department of Computer Science, April 1997. [Sul97b] Martin Sulzmann. Proofs of Soundness and Completeness of Type Inference for HM(X). Research Report YALEU/DCS/RR-1102, Yale University, Department of Computer Science, February 1997. [TJ92] Jean-Pierre Talpin and Pierre Jouvelot. The type and e ect discipline. In Seventh Annual IEEE Symposium on Logic in Computer Science, Santa Cruz, California, pages 162{173, Los Alamitos, California, June 1992. IEEE Computer Society Press. [VHJW96] Cordelia V.Hall, Kevin Hammond, Simon L. Peyton Jones, and Philip L. Waderler. Type classes in haskell. ACM TOPLAS, 18(2):109{138, March 1996.
A Proof of Theorem 20 (Soundness) One thing about which we have to be aware is when we apply a substitution to a typing judgment C; ?
`
e:
Because we only allow constraints in solved form (constraints in ) in our type system, we have to be sure that a substitution does not cause any inconsistencies. In the type inference algorithm normalization ensures that there are no inconsistencies. S
18
B Proof of Theorem 22 (Completeness)
The following two lemmas can both be proven by a straightforward induction on the derivation . Lemma 20 Given C; ? e : and a substitution such that is consistent with respect to C and ?. Then C; ? e : . Lemma 21 Given C; ? e : and a constraint D such that D e C . Then D; ? e : . We restate Theorem 20 in the following lemma. Lemma 22 (Soundness of W ) Given a type environment ? and a term e. If ; C; ? W e : then C; ? e : , C = C and = . Proof: We apply induction on the derivation W . We only consider one case. The other cases can be proven in a similar style. `
In order to prove completeness we have to do a little more work. The idea is to introduce two intermediate derivations. But the last derivation looks much more like a type inference algorithm. We then show that all derivations have the same expressive power. First, we introduce some basic lemmas. We state them without proof. A detailed discussion can be found in [Sul97b]. The rst lemma states that we can lift entailment between two constraints to the generalized constraints. Lemma 23 Given type environments ?, ? , constraints C; C~ , types ; and substitutions ; ; such that i 0 e e C~o ~ ? ? , C C and fv(?) . Then Co ~ ?; ). where Co = gen2 (C; ?; ) and C~o = gen2 (C; The next lemma is similar to the previous one. It is simply formulated for types. Lemma 24 Given type environments ?, ? , constraints i C; C~ , types ; and substitutions ; ; such that 0 e i ? ? , C C~ , C and fv(?) . i Then ~o o where o = gen1 (C; ?; ) and ~o = ~ ?; ). gen1 (C; By the next Lemma we lift some properties about constraints and substitution to the same constraints but extended substitution. Lemma 25 Given constraints C1 ; C and substitutions ; 1 ; : : : ; n ; ; 1 such that 1 C1 = C1 ,0 C e 1 C1 , 1 0 = 1 : : : n, fv(?) , 1 fv(?) . Then C e ( )C1 . The next Lemma is similar to the previous one but it is stated for the i relation. Lemma 26 Given a constraint C , type schemes ~; and substitutions ; 1 ; : : : ; n ; ; 1 such that 0 1 ~ = ~ , C i 1 ~ , = 1 : : : n , fv(?) , 0 1 i ( )~ . 1 fv(?) . Then C Now, we introduce the intermediate derivations. We introduce a derivation 2 which is based on derivation in gure 1. Instead of rule ( Elim) we have the following new (Inst) rule in 2 : (Inst) C; ? 2 x : (x : ? C i ) All other rules stay unchanged. The idea of derivation 2 is simply to enforce ( Elim) steps as early as possible. Next, we consider a syntax directed derivation s . We also want to get rid of the ( Intro) rule. This rule
`
`
`
2 S
`
`
`
`
0
`
0
D
W
2 ; C2 ; ? 0 = 1t 2 = C1 ^ C1 ^ ( 1 = 2 ! ) `
e1 : 1
`
(C; ) = normalize(D; ) W e1 e2 : fv(?) ; C; ?
W
e2 : 2
new
e1 : 1
1 C1
= C1
1 1
0
= 1
0
e2 : 2
2 C2
= C2
2 2
1?
e1 : 1 C;
`
2?
`
= 2
0
`
e1 : 1 C; ?
`
0
`
t
`
0
`
0
e 2 : 2
00
t
0
`
0
00
t
00
`
`
!
`
0
0
8
`
!
C; ?
0
We also now that e ( 2 = 1 ( )) because the constraint ( 1 = 2 ) has been resolved by normalization. Hence, we can rst apply the (Equ) rule and then the (App) rule and get `
`
0
`
e2 : 2
W.l.o.g. we can assume that all identi er in ? are contained in e1 and e2 and not more. This fact and normalization ensures that is consistent in C and ?. Then we can apply Lemma 20 and obtain C; ?
0
With Lemma 21 we can conclude that C;
0
`
t
`
0
0
and C2 ; 2 ?
0
`
`
`
`
0
`
0
We apply the induction hypothesis to the left and right premise and get C1 ; 1 ?
`
0
0
j
0
`
0
Case (App) 1 ; C1 ; ?
0
`
0
`
e1 e2 : ( )
`
2
`
8
`
8
19
is combined with the (Let) rule and the rest of the rules remain unchanged: (Var) C; ? s x : (x : ? C i ) `
2
`
C; ?x :x : `s e : C; ?x `s x:e : !
Case (Let) We have the following situation: C ; ?x `2 e : C ; ?x :x : `2 e : C ; ?x `2 let x = e in e : 0
0
0
0
0
^
0
^
00
^
`
00
`
`
0
`
`
0
0
`
^
^
0
`
0
C1 ; ?x `s e : (o ; Co ) = gen(C1 ; ?x; ) C `i o C `e Co : 0
^
0
`
`
0
`
Note, in the (Let) we implicitely state that the constraint C C is in solved form. Remember that the set of constraints of solved forms is not necessarily closed under in general. That means, when we apply the (Let) we always have to ensure that C C is in solved form. How these derivations are connected is stated in the next lemmas. The rst two lemmas can both be proven by a straightforward induction on the derivation relation. Lemma 27 (Equivalence of and 2 ) Given a type environment ?, a constraint C , a term e and a type scheme . Then C; ? e : i C; ? 2 e : . Lemma 28 (Soundness of s ) Given C; ? s e : . Then C; ? e : . We now show that s is complete with respect to 2 and W is complete with respect to 2 . In order to prove it we have to strengthen the assumption about the given type environment. This is due to the (Let) rule where the two premises use di erent type environments. Therefore, we introduce the following de nition. De nition 28 Let C be a constraint and ? and ? be type environments such that ? = x1 : 1 ; : : : ; xn : n and ? = x1 : 1 ; : : : ; xn : n . Then C i ? ? i C i i i i : i 1; : : : ; n . Lemma 29 (Completeness of s ) Given C ; ? 2 e : , C i ? ? and ? is realizable in C . Then (a) = : C; ? s e : C e C (b) otherwise : C; ? s e : (o ; Co ) = gen(C; ?; ) 0
0
0
`
0
0
00
0
0
0
00
0
`
C; ?x `s e : (C ; ) = gen(C; ?x ; ) C ; ?x :x : `s e : C ^ C ; ?x `s let x = e in e :
(Let)
0
First, we consider the case if is a type . We apply the induction hypothesis to left premise and get C1 ; ?x s e : and C e C1 . We set (o ; Co ) = gen(C1 ; ?x ; ). It is an easy observation that C i o holds. Now, we apply the induction hypothesis to the right premise. This yields C2 ; ?x :x : o s e : and C e C2 . We know that C e Co C2 which ensures that Co C2 is in solved form. We can apply the (Let) rule and obtain Co C2 ; ?x s let x = e in e : . Now, let us consider the case if is a type scheme. Application of the induction hypothesis to the left premise yields: 0
C; ? `s e1 : 1 ! 2 C; ? `s e2 : 1 C; ? `s e1 e2 : 2
(App)
0
0
0
(Abs)
0
0
We can conclude that ? :x : is realizable in C because C ; ? i2 e : . Then we can apply the induction hypothesis to the right and get 0
0
0
0
`
C2 ; ?x :x : o `s e :
C
0
0
e
`
C2 :
We can conclude that C e Co C2 which ensures that Co C2 is in solved form. We can apply the (Let) rule and get 0
`
^
^
Co ^ C2 ; ?x `s let x = e in e : 0
`
0
`
`
`
`
`
0
f
0
f
0
`
0
0
8
g
g
2 f
0
`
0
`
0
C
0
`
e
0
Co C
0
`
0
`
`
e : and
0
`
i
`
o
Proof:
We use induction on the derivation limitation we only show one case.
s.
0 fv(?)
C
0
0
0
0
0
e
`
C 0
`
i
0
0
s
`
0
0
Proof: We use induction on the derivation
to space limitation we only show one case.
`
Case (App) We have the following situation: 0
s e1
`
: 1 C ;? 0
0
20
) Given C ; ?
where = gen1 (C ; ? ; ) and = gen1 (C; ?; ).
C ;?
Due to space
? ? . Then
W
for some substitution , constraint C and type such that,
0
`
`
0
; C; ? `W e :
0
0
0
i `
0
g
`
0
Lemma 30 (Completeness of
0
2 C ; ? s ` e1 e2 : 1
!
0
0
0
0
s e2
`
: 1 0
s.
Due
Application of the induction hypothesis yields
Then we can deduce that (
01 fv(?) 0 i 0 1 C1 ` 1 1 10 0 0 0 1 = gen1 (C ; ? ; 10 ! 20 ) 1 = gen1 (C1 ; 1 ?; 1 ) 1 ; C1 ; ? C 0 `e
`
W
e1 : 1
1
2 ; C2 ; ? C 0 `e
`
W
0
0
0
0
2
It remains to show that
8
0
0
i `
0
0
`
0
0
0
0
` 0
0
`
0
0
^
0
t
t
^
0
!
0
e
`
(
0
`
0
0
0
0
0
0
0
0
`
`
0
) 1 (
C
0
e `
(
0
!
0
0
0
0
0
0
0
0
0
0
0
e
) 2 ! 2 : 0
)( ) 2
0
0
0
`
0
`
0
Co
`
C
i
0
`
o
0
0
0
0
0
for some substitution , constraint C and type such that,
)( ) = 2 and 0
C:
(
; C; ? `W e :
0 fv(?)
C
0
e
`
Co C 0
0
i
`
o 0
0
where (o ; Co ) = gen(C; ?; ). Proof: First, we apply Lemma 27 in order to get a derivation in `2 . Then, we can apply Corollary 3 and get C; ? `s e : (o ; Co ) = gen(C; ?; ) (3)
0
`
e
0
0
)D:
0
0
0
0
C
`
where (o ; Co ) = gen(C; ?; ). Now we have everything at hand to prove completeness of type inference. Theorem 29 Given C ; ? ` e : , C `i ? ? and ? is realizable in C . Then
0
0
i
0
0
C
0
C C
such that
But that means (C ; ) is a normal form of (D; ). Because HM(X) satis es the principal constraint property we know that there exist a principal normal form of (D; ). That means we get normalize(D; ) = (C; ) where 0
e
`
C; ? `s e :
0
By de nition it holds that ( then we get that
0
t
0
0
0
0
0
0
0
0
0
Before we prove the main theorem we state the following corollary which is based on Lemma 29. Corollary 3 Given C ; ? 2 e : , C i ? ? and ? is realizable in C . Then
0
0
0
0
`
j
0
`
o o where
`
0
0
i
0
!
0
`
Now we can apply Lemma 24 and get i o o as desired. Finally, we apply the (App) rule and get W e1 e2 : ( ). fv(?) ; C; ?
`
0
0
0
C
0
We have already convinced us in Lemma 8 that we can use i2 instead. Then it is not dicult to follow that both above statement must have been derived from C e (1 1 )C1 C i (1 1 ) 1 1 2 C e 2 2 C2 C i (2 2 ) 2 1 where i 's are solution to the bound type variables. 0 We set = 1 2 then we get that fv(?) . We de ne 3 = [ 2 = ] and = 1 2 3 . We set D = C1 C2 ( 1 = 2 ). We now apply Lemmas 25 and 26. In this case we additionally deal with substitutions ; 1 ; 2 ; 3 . Simply think that is now attached with . The same holds for 1 and 1 and also 2 and 2 . This does not cause any trouble because i 's operate only on bound type variables. We get that C e ( )C1 C e ( )C2 C e ( ) 1 1 2 C e ( ) 2 1 : We can conclude that `
j
0
2 2 2 0
fv(?)
)
1 1 1 0
) fv(?) =
We have already seen that ( )( ) = 2 . Because of the choice of the substitution it holds also that ( )( ) = 2 . And from 2 we get ( )( ) = 2 . That means, we know that
)
i `
0
o = gen1 (C ; ? ; 2 ) and o = gen1 (C; ?; ( )):
i i . We want to W.l.o.g. we assume i = :C rename all bound type variables, we de ne a renaming substition = [ = ]. We now deal with the type scheme
:Ci i . From 1 we know that 8
0
Hence, we get that
02 fv(?) i 0 0 ` 2 2 2 2 = gen1 (C2 ; 2 ?; 2 )
e2 : 2
2 C2 2 = gen1 (C ; ? ; 1 ) 0
C
j
(1)
and
0
) fv(?) = (
(2)
C
21
0
e
`
Co C
0
i
`
o
0
After that we apply Lemma 30 (completeness of and get 0 ~ ? W e : ~ ; C; fv(?) ~ ~ (~o ; Co ) = gen(C; ?; ~) i ~o o : C e C~ `
W
)
0
`
`
`
0
It remains to show 1. C i ~o 2. C e C~o . We know that C e C~ with Lemma 23 we get that Co e C~o . From 3 we know that C e Co and because e is transitive we get that C e C~o . Also, we know that C i o and because i is transitive and closed under strengthening the constraint we get C i ~o . 0
`
0
`
0
0
0
0
`
0
`
0
0
`
0
0
`
0
`
0
`
0
`
`
0
Then we get Theorem 22 as a corollary from Theorem 29.
22
