Mark Shields Oregon Graduate Institute Erik Meijer Utrecht University Type-Indexed Rows Mark Shields Oregon Graduate Institute Erik Meijer Utrecht University

Motivation Investigate essence of closed-world type-based overloading eg + is type-indexed product of Int ® Int ® Int and Real ® Real ® Real functions Þlightweight alternative to Haskell’s class system?

Motivation Investigate essence of closed-world type-based overloading eg + is type-indexed product of Int ® Int ® Int and Real ® Real ® Real functions Þlightweight alternative to Haskell’s class system? probably not!

Motivation Investigate essence of closed-world type-based overloading eg + is type-indexed product of Int ® Int ® Int and Real ® Real ® Real functions Þlightweight alternative to Haskell’s class system? probably not! Find compromise between XML types unions, “unordered” tuples and functional programming types labeled variants and records Þreplace custom XML-centric languages with single Haskell-like language?

Motivation Investigate essence of closed-world type-based overloading eg + is type-indexed product of Int ® Int ® Int and Real ® Real ® Real functions Þlightweight alternative to Haskell’s class system? probably not! Find compromise between XML types unions, “unordered” tuples and functional programming types labeled variants and records Þreplace custom XML-centric languages with single Haskell-like language? promising, but unimplemented

Overview Present lTIR, a typed polymorphic l-calculus Like a polymorphic extensible record calculus (lREC) label-indexed rows lacks/membership/insertion constraints constrained/qualified polymorphism records and variants But labels are not primitive type-indexed rows insertion and equality constraints type-indexed products (TIPs) and type-indexed co-products (TICs) newtypes

lREC Combinators (1) lREC Labels l lREC Kinds Type Row lREC Constraints l ins r lREC Types Empty : Row (l: _ # _) : Type ® Row ® Row One : Row ® Type All : Row ® Type eg (xCoord: Int # yCoord: Real # Empty) All (xCoord: Int # yCoord: Real # Empty) One (isInt: Int # isBool: Bool # Empty)

lTIR Combinators (1) lTIR Kinds Type, Row lTIR Constraints t ins r, t eq u lTIR Types Empty : Row ( _ # _) : Type ® Row ® Row One : Row ® Type All : Row ® Type eg ( Int # Real # Empty) All ( Int # Real # Empty) One ( Int # Bool # Empty)

lREC Combinators (2) lREC Terms eg Triv : All Empty (l: _ && _) : " a:Type b:Row . l ins b Þ a ® All b ® All (l: a # b) (Inj l: _) : " a:Type b:Row . l ins b Þ a ® One (l: a # b) eg (xCoord: 1 && yCoord: 2.0 && Triv) : All (xCoord: Int # yCoord: Real # Empty) (Inj isInt: 1) : " a:Row . isInt ins a Þ One (isInt: Int # a)

lTIR Combinators (2) lTIR Terms eg Triv : All Empty ( _ && _) : " a:Type b:Row . a ins b Þ a ® All b ® All ( a # b) (Inj _) : " a:Type b:Row . a ins b Þ a ® One ( a # b) eg ( 1 && 2.0 && Triv) : All ( Int # Real # Empty) (Inj 1) : " a:Row . Int ins a Þ One ( Int # a)

lREC Combinators (3) lREC Patterns eg Term combinators may also appear within l-abstraction patterns { } allows discrimination - patterns tried left-to-right eg \(xCoord: x && yCoord: y && Triv) . x + floor y \(yCoord: y && _) . y * 2 { \(Inj isInt: x) . x == 0 ; \(Inj isBool: y) . not y } : " a:Row . isInt ins a, isBool ins a Þ One (isInt: Int # isBool: Bool # a)®Bool

lTIR Combinators (3) lTIR Patterns eg Term combinators may also appear within l-abstraction patterns { } allows discrimination - patterns tried left-to-right eg \( x && y && Triv) . x + floor y \( y && _) . y * 2 { \(Inj x) . x == 0 ; \(Inj y) . not y } : " a:Row . Int ins a, Bool ins a Þ One ( Int # Bool # a)®Bool

lREC Type Equality Types equal up to permutation of rows All (l1: t # l2: u # Empty) º All (l2: u # l1: t # Empty) Records equal up to permutation of fields (l1: t && l2: u && Triv) º (l2: u # l1: t && Triv)

lTIR Type Equality Types equal up to permutation of rows All ( t # u # Empty) º All ( u # t # Empty) !!! TIPs equal up to permutation of fields ( t && u && Triv) º ( u # t && Triv)

Problem 1 lREC rows are label-indexed Type Term (xCoord: Int # yCoord: Int # Empty) : Row Term (xCoord: 1 && yCoord: 2 && Triv) : All (xCoord: Int # yCoord: Int # Empty)

Problem 1 lTIR rows are type-indexed Type Term ( Int # Int # Empty) : Row (well-kinded, but useless type) Term ( 1 && 2 && Triv) error: the constraint Int ins (Int # Empty) is unsatisfiable To be practical, lTIR cannot rely on structural inequivalence alone to distinguish row elements

Solution: Newtypes A newtype is a freshly named type synonym with explicit rather than implicit isomorphism eg with declarations newtype A = Int newtype B = \a . a newtype C = \a . a then Int, A, B Int, C Int are distinct types eg (1 && A 2 && B 3 && C 4 && Triv) : All (Int # A # B Int # C Int # Empty) Notice A resembles a monomorphic label B, C resemble polymorphic labels

Problem 2 lTIR unification is not unitary Unification of with (\(x && y && Triv) . (x, y)) (1 && True && Triv) Unification of All (a # b # Empty) with All (Int # Bool # Empty) yields the two substitutions [a |® Int, b |® Bool] , [a |® Bool, b |® Int] Choosing one unifier destroys completeness Maintaining all unifiers is dangerous

Solution: Equality Constraints Obvious solution is to defer such unification problems let f = (\(x && y && Triv) . (x, y)) (1 && True && Triv) in fst f + snd f : Int f : " a:Type b:Type . (a # b # Empty) eq (Int # Bool # Empty), a ins (b # Empty) Þ (a, b) Notice how equality constraint was eliminated when g specialised to (Int, ...) and (..., Int) Result is 2

Problem 3 lTIR is too polymorphic to simulate lREC newtype A = \a . a newtype B = \a . a (A 1 && A True && B 1 && Triv) : All (A Int # A Bool # B Int # Empty) But should be ill-typed \r . ((\(A x && _) . x) (A 1 && r)) : " a:Type b:Row c:Row . (A a # b) eq (A Int # c), A a ins b, A Int ins c Þ All c ® a But should be " b:Row . A Int ins b Þ All b ® Int

Solution: Opaque Newtypes Opaque newtypes “hide” their type arguments within insertion constraints newtype opaque A = \a . a newtype opaque B = \a . a (A 1 && A True && B 1 && Triv) : error: the constraint A Int ins (A Bool # B Int # Empty) is unsatisfiable \r . ((\(A x && _) . x) (A 1 && r)) : " b:Row . A Int ins b Þ All b ® Int or " a:Type b:Row . A a ins b Þ All b ® Int

Encoding Datatypes Tuples are easily encoded using a newtype to labels each posititon Recursive sum-of-product datatypes also easily encoded data Tree = \a . Node (Tree a, a, Tree a) | Leaf becomes newtype Tree = \a . One ((Node a) # (Leaf a) # Empty) newtype Node = \a . (Tree a, a, Tree a) newtype Leaf = \a . () Node t º Tree (Inj (Node t)) Leaf º Tree (Inj (Leaf ()))

Encoding Closed World Overloading intPlus : Int ® Int ® Int realPlus : Real ® Real ® Real (+) = (\(x && _) . x) (intPlus && realPlus && Triv) : " a:Type b:Row . a ins b, (a # b) eq ((Int ® Int ® Int) # (Real ® Real ® Real) # Empty) Þ a \y . (1 + 1, 1.0 + y) : Real ® (Int, Real)

Encoding Overloading (cont) 1.0 + 1 error: the constraint ((Real ® Int ® a)# b) eq (Int ® Int ® Int) # (Real ® Real ® Real) # Empty) is unsatisfiable

XML Document type definition (DTD) is a regular tree grammar, document is a tree Each production defines an element Production rhs is a regular expression eg (in idealised syntax!) element Msg = (((To|Bcc)* & From), Body) element Body = P* element To = String (...etc...) But Appendix E. Deterministic Content Models For compatibility, it is required that content models in element type declarations be deterministic.

Encoding XML DTDs Sugar XML DTDs may be directly embedded within lTIR (t | u) º One (t # u # Empty) (...etc...) (t & u) º All (t # u # Empty) (...etc...) t* º List t t? º Option t XML DTDs may be directly embedded within lTIR elements ® newtypes regular expressions ® types eg newtype Msg = (((To|Bcc)* & From), Body) newtype Body = P* newtype To = String (...etc...)

Encoding XML Documents However, lTIR “native” syntax looks nothing like XML Mgs (([Inj (To “Mark”), Inj (Bcc “Erik”)] && From “Erik” && Triv), Body [P “1st para”, P “2nd para”]) But possible to exploit determinacy of regular expressions to support native XML syntax - compiler translates this into native syntax during type checking <Msg><To>Mark</To><Bcc>Erik</Bcc> <From>Erik</From> <Body><P>1st para</P> <P>2nd para</P></Body> </Msg>

Semantics/Implementation We may reduce type indexing to natural num indexing Let £ be a partial ordering on types which is stable under substitution, ie t £ u Þ qt £ qu (We use a lexicographic ordering on the pre-order flattening of t & u in canonical row order) A TIP is a tuple in canonical row order, eg [[ All (Bool # Int # Empty)]] = { <v1, v2> | v1 Î [[Int]], v2 Î [[Bool]]}^ A TIC is a pair of a canonical index and a value, eg [[ One (Bool # Int # Empty)]] = { <1, v> | v Î [[Int]]}^ È { <2, v> | v Î [[Bool]]}^

Semantics/Implementation (cont) Since canonical order may not be known at compile-time, indices must be passed at run-time. Eg \(x && y && Triv) . (x, y) : " a:Type b:Type . a ins (b # Empty) Þ All (a # b # Empty) ® (a, b) is denoted/implemented by lw . lp . let (x, p’) = remove w from p in let (y, _) = remove 1 from p’ in <x, y> Propagation of indices at run-time parallels the propagation of insertion constraints at compile-time

Semantics/Implementation (cont) Dictionary translation (Wadler & Blott) makes index passing explicit Constraint simplifier generates both absolute indices, eg < w : Bool ins (Int # Char # Empty), C > Þ < C | w = 2> and relative indices, eg < w : Bool ins (Int # a # Empty), C > Þ < w’ : Bool ins (a # Empty) , C | w = w’ + 1>

Correctness Type checking builds upon constraint entailment: Proof-theoretic entailment is incomplete w.r.t. model-theoretic entailment We currently do not exploit ordering properties of types, but could do so should incompleteness prove problematic Type soundness holds Type inference builds upon constraint simplifier: Does not reduce constraints to solved form (cf HM(X)) Soundness and completeness of inference holds Completeness somewhat subtle, and must use model- rather than proof-theoretic entailment

Practicality lTIR is the kernel of XMl, a functional programming language with direct support for XML types & terms Type inference is likely to have complexity above EXP But simplifier is designed to eliminate common row equality constraints in O(n log n) type comparisons (cf polymorphic record calculi) But at this time implementation is not complete enough to test practicality on actual programs

Related Work Like polymorphic extensible records... (Gaster et al) … but without labels Like set constraints... (Aiken et al) … but with explicit idempotence constraints Like intersection types... (Reynolds et al) … but without coherence Almost instance of OML… (Jones) … but with finer instantiation ordering Almost instance of HM(X)… (Odersky et al) … but with coarser instantiation ordering … and without normalisation requirement

Conclusions Small calculus which naturally supports many conventional type-theoretic features recursive sum-of-products extensible datatypes monomorphic & polymorphic extensible records type-based overloading Also supports XML-style document type definitions Complete constraint entailment seems overly expensive Simplifier is quite weak, again to avoid blow ups Implementation still in progress… ... so practicality still open See Part I of my thesis the gory details (avail mid Feb)