Presentation is loading. Please wait.

Presentation is loading. Please wait.

Singleton Kinds and Singleton Types Christopher A. Stone August 2, 1999 Thesis Committee Bob Harper, chair Peter Lee John Reynolds Jon Riecke (Bell Laboratories)

Similar presentations


Presentation on theme: "Singleton Kinds and Singleton Types Christopher A. Stone August 2, 1999 Thesis Committee Bob Harper, chair Peter Lee John Reynolds Jon Riecke (Bell Laboratories)"— Presentation transcript:

1 Singleton Kinds and Singleton Types Christopher A. Stone August 2, 1999 Thesis Committee Bob Harper, chair Peter Lee John Reynolds Jon Riecke (Bell Laboratories)

2 Dissertation Summary Study of language with singleton kinds and singleton types –Models intermediate representation of TILT compiler Proofs of important language properties –Decidability of typechecking –Algorithms for typechecking Context-sensitive type-equivalence algorithm –Soundness of type system Here I will concentrate on singleton kinds.

3 TILT Compiler for Standard ML Reimplementation of the TIL prototype [Tarditi et. al. 96] –Compiles full Standard ML –Handles separate compilation, larger programs Key technologies –Intensional Polymorphism [Harper & Morrisett 95] –Typed Compilation [Morrisett 95]

4 Typed Compilation Uses strongly-typed intermediate language(s) Compiler passes preserve well-typedness prog1 : t prog2 : t Common Subexpression Elimination prog1 : t1 prog2 : t2 Closure Conversion

5 Advantages of Typed Compilation Retains information –For optimizations –For improved code generation –For safety certificates Also a handy compiler debugging tool! –Typechecking after each transformation finds many common implementation errors. –Improves compiler robustness

6 One Pass: Phase Splitting SML module system –Structures package types, values, and structures –Functors map modules to modules Phase Splitting transformation [Harper et al. 90] –Purpose: Translate from language with modules to a language without –Every module splits into a type part and a value part: –Interfaces split in a parallel fashion

7 An Interface for Queues structure Queue: sig type elem type queue val empty : queue val enqueue : elem * queue -> queue val dequeue : queue -> elem * queue end

8 Phase Splitting Queues structure Queue: sig type elem type queue val empty : queue val enqueue : elem * queue -> queue val dequeue : queue -> elem * queue end Queue_c : {elem : TYPE, queue : TYPE} Queue_r : {empty : …, enqueue : …, dequeue : …}

9 Queues of Strings structure StringQueue: sig type elem = string type queue val empty : queue val enqueue : elem * queue -> queue val dequeue : queue -> elem * queue end

10 Queues of Strings structure StringQueue: sig type elem = string type queue val empty : queue val enqueue : elem * queue -> queue val dequeue : queue -> elem * queue end Makes elem a synonym for string

11 Queues of Strings structure StringQueue: sig type elem = string type queue val empty : queue val enqueue : elem * queue -> queue val dequeue : queue -> elem * queue end StringQueue_c : {elem : ????, queue : TYPE} StringQueue_r : {empty : …, enqueue : …, dequeue : …}

12 A First Try structure StringQueue: sig type elem = string type queue val empty : queue val enqueue : elem * queue -> queue val dequeue : queue -> elem * queue end StringQueue_c : {elem : TYPE, queue : TYPE} StringQueue_r : {empty : …, enqueue : …, dequeue : …}

13 How to remember elem  string ? Option 1: Substitution –Replace elem with string everywhere [Shao 99] Must remove indirect references as well –But in general this causes duplication of types Instead of string, might have a big, complex type Replacing elem with this type everywhere could cause blow-up in code size In TILT types can correspond to run-time computations

14 How to remember elem  string ? Option 1: Substitution –Replace elem with string everywhere [Shao 99] Must remove indirect references as well –But in general this causes duplication of types Instead of string, might have a big, complex type Replacing elem with this type everywhere could cause blow-up in code size in TILT types can correspond to run-time computations Option 2: Put definitions in the kind structure

15 What is a kind? In SML, types form a little language Kinds are the “types of types” –key and key pair are well-formed types –pair and pair pair are not type key = int type ‘a pair = ‘a * ‘a key :: TYPE pair :: TYPE  TYPE

16 Singleton Kinds S(A) is “kind of all types interchangeable with A ” –i.e., B :: S(A) if and only if  B  A Advantages –Single construct isolating issues of type definitions –Not conflated with ML module system –Syntactically simple –Necessary for type-preserving polymorphic closure conversion [Minamide et al. 96]

17 Queues of Strings with Singletons structure StringQueue: sig type elem = string type queue val empty : queue val enqueue : elem * queue -> queue val dequeue : queue -> elem * queue end StringQueue_c : {elem :: S(string), queue :: TYPE} StringQueue_r : {empty : …, enqueue : …, dequeue : …}

18 Typechecking with Singletons Want to be able to typecheck after phase-splitting –Initial attempts to program typechecker failed Rejected valid inputs Went into infinite loops –Question: is typechecking even decidable? The key to typechecking is determining equivalence of type constructors

19 MIL 0 Syntax (excerpt) Type Constructors A,B ::= int | bool |... |  |  :K.A | A B | |  1 A |  2 A Kinds K,L ::= T | S(A) |  : K.L (K  L) |  : K.L (K  L)

20 Static Semantics Standard rules for dependent kinds and  - equivalence of constructors, plus: –Singleton introduction and elimination If A : T then A : S(A) If A : S(B) then A  B : T –Subkinding relation: S(A)  T Lifted to  and  kinds as usual –Two non-standard typing rules Ensures types preserved under  -equivalence e.g., can show if f : T  T then f :  :T. S(f  )

21 Singletons make Equivalence Interesting Dependency on kinds of free variables:  :: T  S( int )   2   int :: T  ::  ::T.S(  )   1    2  :: T  :: T  S( int )     :T. int :: T  T

22 Singletons make Equivalence Interesting Dependency on kinds of free variables:  :: T  S( int )   2   int :: T  ::  ::T.S(  )   1    2  :: T  :: T  S( int )     :T. int :: T  T Dependency on classifying kind –Cannot show  ::T. int   ::T.  :: T  T

23 Singletons make Equivalence Interesting Dependency on kinds of free variables:  :: T  S( int )   2   int :: T  ::  ::T.S(  )   1    2  :: T  :: T  S( int )     :T. int :: T  T Dependency on classifying kind –Cannot show  ::T. int   ::T.  :: T  T –But,  ::T. int   :T.  :: S( int )  T holds!

24 Singletons make Equivalence Interesting Dependency on kinds of free variables:  :: T  S( int )   2   int :: T  ::  ::T.S(  )   1    2  :: T  :: T  S( int )     :T. int :: T  T Dependency on classifying kind –Cannot show  ::T. int   ::T.  :: T  T –But,  ::T. int   :T.  :: S( int )  T holds! Interestingly,  -equivalence is admissible!

25 Typechecking with Singletons Not immediately obvious that typechecking is decidable in the presence of singletons Standard context-free rewriting techniques not directly applicable –Adapting these techniques can be hard e.g., Lillibridge, Curien and Ghelli My method (inspired by Coquand) –Define a direct comparison algorithm –Prove it correct using logical relations

26 Algorithmic Equivalence Deterministic rules for   A  B :: K –Expect agreement with   A  B :: K for well-formed A, B Strategy: reduce to tests at kind T 

27 Algorithmic Equivalence Deterministic rules for   A  B :: K –Expect agreement with   A  B :: K for well-formed A, B Strategy: reduce to tests at kind T    A  B ::  ::K.L if    1 A   1 B :: K and    2 A   2 B :: [  1 A/  ]L

28 Algorithmic Equivalence Deterministic rules for   A  B :: K –Expect agreement with   A  B :: K for well-formed A, B Strategy: reduce to tests at kind T    A  B ::  ::K.L if    1 A   1 B :: K and    2 A   2 B :: [  1 A/  ]L   A  B ::  ::K.L if  ::K  A   B  :: L

29 Algorithmic Equivalence Deterministic rules for   A  B :: K –Expect agreement with   A  B :: K for well-formed A, B Strategy: reduce to tests at kind T    A  B ::  :K.L if    1 A   1 B :: K and    2 A   2 B :: [  1 A/  ]L   A  B ::  :K.L if  ::K  A   B  :: L   A  B :: S(C) always At kind T head-normalize, compare subcomponents –Includes expansion of definitions

30 Correctness Proof Hardest part is showing completeness of the algorithm w.r.t. provable equivalence Approach: logical relations –Define “logical” equivalence –Show logical equivalence implies algorithmic equivalence (  ) –Show provable equivalence (  ) implies logical equivalence.

31 Logical Relations Provable equivalence depends on context and classifying kind Also, relating open terms Suggests Kripke logical relations (relations indexed by a “world” and a kind) –In our case, a world is a typing context –Ordering on worlds is prefix ordering

32 A Natural Attempt Relatively standard Kripke logical relations: –A is B in T [  ] iff   A  B :: T –A is B in  ::K.L [  ] iff  ’   if A’ is B’ in K [  ’] then A A’ is B B’ in [A’/  ]L [  ’] This proof nearly goes through

33 The Problem We must show logical equivalence is symmetric and transitive This requires showing the algorithm symmetric and transitive Arbitrary choices in presentation of the algorithm prevent a direct proof, e.g.,    A  B ::  ::K.L if    1 A   1 B :: K and    2 A   2 B :: [  1 A/  ]L

34 A Revised Algorithm Idea: maintain a context and a classifier for each constructor –6 place relation  1  A 1 :: K 1   2  A 2 :: K 2 –Uses both alternatives at choice points one on each side –Maintains invariant that  1   2 and K 1  K 2 Correctness of revised algorithm implies correctness of original algorithm

35 Revised Logical Relations Because algorithm has two classifiers and two contexts, logical relations must as well: –A 1 in K 1 [  1 ] is A 2 in K 2 [  2 ] Definition retains same flavor as before –e.g., two constructors are related at (related)  -kinds at two worlds if for each pair of future worlds … Does not seem possible to formulate as a standard Kripke relation indexed by pairs (  1,  2 ) and (A 1,A 2 )

36 Summary of Decidability Soundness provable directly: if   A  B :: K then   A  B :: K Proof just outlined shows: if   A  B :: K then   A  B :: K Easy corollary: Algorithm terminates on all inputs Thus equivalence is decidable. Thus validity of type constructors and their kinds is decidable [Stone and Harper 00]

37 Singleton Types S(v :  ) is the type of terms of type  equivalent to v –Restriction: only values may appear in singletons –Strong equivalence (no  ) Equivalence only depends on typing context, not classifier Similar proof strategy shows typechecking decidable Potential use: TILT cross-module inlining –Interfaces can expose code of module components

38 Type Soundness Want to show “well-typed programs don’t go wrong” Mostly standard proof outline –Evaluation preserves well-typedness –Well-typed programs don’t get stuck” But, proof requires consistency property –e.g., int and bool are not provably equivalent –Follows directly by correctness of equivalence algorithm

39 Adding Intensional Polymorphism Constructs for runtime case analysis (and primitive recursion) of type constructors –Permits improved calling conventions, data representation even when types statically unknown [Harper and Morrisett 95] All the proofs go through with relatively minor modifications. –Relatively robust proof technique

40 Summary of Contributions Thorough study of a language MIL 0 with singleton kinds and singleton types –Two very different forms of equivalence Results for type soundness and decidability Typechecking algorithms –TILT compiler uses those for singleton kinds –General framework for context-sensitive equivalences

41 Open Questions Improved theory of singleton types –Currently appears to require too many type annotations to be practical –S(v) instead of S(v : t) ? Nontrivial equivalences between recursive types –Extension in TILT implementation works in practice –No obvious way to make algorithm obviously transitive.

42 Related Work Aspinall [94, 97] –Studied -calculus with singleton types –Somewhere between my singleton types and kinds Has  -equivalence, not , strong equivalence for lambda abstractions, singletons contain type annotations –Gave a PER model –Showed existence of principal types –No typechecking or equivalence algorithm (though conjectured decidable)


Download ppt "Singleton Kinds and Singleton Types Christopher A. Stone August 2, 1999 Thesis Committee Bob Harper, chair Peter Lee John Reynolds Jon Riecke (Bell Laboratories)"

Similar presentations


Ads by Google