1. Type Analysis and Typed Compilation Stephanie Weirich Cornell University

2. ICFP '98 Outline Typed Compilation background Type Analysis background Initial framework - Type Passing Problems with Type Passing Type Erasure framework Closure Conversion comparison Related Work

3. ICFP '98 Traditional Compilation Untyped Assembly Language Untyped Intermediate Language Typed Abstract Syntax Implicitly Typed Source Language Compilation is a series of translations between several languages

4. ICFP '98 Typed Compilation Assembly Language Typed Intermediate Language Typed Abstract Syntax Most of those languages are typed, and the types are translated with the terms Implicitly Typed Source Language

5. ICFP '98 Typed Compilation Safety –“well-typed programs can’t go wrong” –Types describe invariants maintained by the compiler Performance –Types provide information which may be used by the compiler for optimization –Tag-free garbage collection –Data layout control

6. ICFP '98 Type Analysis Create functions from types to values Code may branch on an unknown type fun toString x:a => (typecase a of int => Int.toString | char => Char.toString | * => fn (fst,snd) => “(” ^ (toString fst) ^ “,” ^ (toString snd) ^ “)” ) x

7. ICFP '98 06/08/9 9 Data Layout Optimization Parametric polymorphism requires uniformity of representation for all arguments, regardless of their types. kinds k = T4 | T types t = B4 | t array | a | t ->t terms e,f = x | lx.e | e f | La:k.e | e [t] | ld(e,f) | i | e  f | if0 then else... | malloc(e,e...) | st(e,e,e) ld : (t array * B4) -> t st : (t array * B4 * t ) -> t

8. ICFP '98 06/08/9 9 ICFP '98 Because any array may be passed to a polymorphic function, all arrays must look the same, no matter the type of their elements. A:int Array B:bool Array sub = fn (A:a array,i:int) => wordsub(A,i) Polymorphic Subscript

9. ICFP '98 06/08/9 9 In languages such as C, the type of an array is always known at its use. A[2] B[2] wordsub(A,2) wordsub(B,0)&(1 0 int A[4] bool B[4] Monomorphic subscript

10. ICFP '98 06/08/9 9 ICFP '98 sub = fn (A:a array,i:int) => typecase a of int => wordsub(A,i) | bool => (wordsub(A,i div 32) & (1 0 A:int Array B:bool Array Type Analysis to the Rescue Type analysis allows us to determine the type at run time.

11. ICFP '98 Initial Framework -  i ML Make type abstraction/application explicit (as in System F) (  a. e) [ int ] Add typecase operator typecase t of int =>... | b * g =>... Code execution (operational semantics) now relies on the type system

12. ICFP '98 06/08/9 9 Type Passing Semantics (  a. (A:a array,i:int). typecase a of int => wordsub(A,i) bool => (wordsub(A,i div 32) & (1 0) [int] (A,3) sub[int](A,3) wordsub(A,3) typecase int of int => wordsub(A,3) bool => (wordsub(A,3 div 32) & (1 0

13. ICFP '98 Typechecking To typecheck a typecase term we annotate the term with its return type: tostring  a. x:a. (typecase [ d.d -> string ] a of int => Int.toString | char => Char.toString | b * g => fn (fst,snd):b*g => “(” ^ (toString[b] fst) ^ “,” ^ (toString[g] snd) ^ “)” ) x Then we check that each branch satisfies that type with the appropriate type substitution. The return type of the entire term is a substituted for d in the annotated type.

14. ICFP '98 06/08/9 9 ICFP '98 Problems Issues about expressiveness –Complicates low-level constructs –Can’t express some optimizations –Can’t express abstraction boundaries

15. ICFP '98 06/08/9 9 Complexity Polymorphic closure conversion –Minamide et al. [1996] –Morrisett et al. [1998] Duplication of effort –Optimization of runtime behavior –Explicit modeling of low level computation Allocation Semantics Typed Assembly Languages Complexity

16. ICFP '98 06/08/9 9 ICFP '98 Inefficiency Must pass all types even if some are never examined TIL -- eliminates unexamined run-time types in ad hoc manner in translation to untyped calculus Inefficiency

17. ICFP '98 06/08/9 9 ICFP '98 No way to hold types abstract if they can always be examined Clients allowed to break abstraction barriers and infer more information than desired HostClient bool refcapability Loss of Abstraction

18. ICFP '98 06/08/9 9 ICFP '98 Solution Pass terms that represent types

19. ICFP '98 06/08/9 9 Type Erasure Semantics sub [int] Rint (A,3)

20. ICFP '98 06/08/9 9 Type Erasure Semantics (  a. x:R(a). (A:a array,i:int). typecase x of Rint => wordsub(A,i) Rbool => (wordsub(A,i div 32) & (1 0) [int] Rint (A,3) sub [int] Rint (A,3) wordsub(A,3) typecase Rint of Rint => wordsub(A,3) Rbool => (wordsub(A,3 div 32) & (1 0

21. ICFP '98 06/08/9 9 Type Erasure Semantics ( . x:R(  ). (A:  array,i:int). typecase x of Rint => wordsub(A,i) Rbool => (wordsub(A,i div 32) & (1 0) [int] Rint (A,3) sub [int] Rint (A,3) wordsub(A,3) typecase Rint of Rint => wordsub(A,3) Rbool => (wordsub(A,3 div 32) & (1 0

22. ICFP '98 06/08/9 9 Formalization Special representation terms: –R int –R  (x,y) A term e which represents a type  has the special type R(  ). –R  (R int, R int ) : R(int  int) Instead of a type, the argument to typecase is a term of type R(  ) The type system tracks the correspondence between a type and its representation

23. ICFP '98 Typechecking To typecheck a typecase term we still annotate the term with its return type: tostring  a. x:a. y:R(a). (typecase [ d.d -> string ] y of Rint => Int.toString | Rchar => Char.toString | R*(r1,r2) as b*g => fn (fst,snd):b*g => “(” ^ (toString[b] fst r1) ^ “,” ^ (toString[g] snd r2) ^ “)” ) x We require that the argument to the typecase be of type R(t) for the typecase term to typecheck. We can then substitute a for d in the annotated type as before.

24. ICFP '98 06/08/9 9 SolutionSolution Everything that happens at run-time is described by the terms Can go to a type erasure semantics Optimization Traditional code optimizers can optimize type representations Sophisticated techniques still possible If a representation is not provided a type may not be analyzed

25. ICFP '98 Typed Closure Conversion At run-time, a first-class function is represented by a code pointer But now x is unbound -- so we change the type of l2 to take another argument A closure is just a code pointer paired with the values of its free variables -- its environment f  x:int. y:int. x + y l1: x:int. l2 l2: y:int. x + y l1: x:int. (l2, x) l2: y,x:int. x + y

26. ICFP '98 (f 3) 4 Typed Closure Conversion Application just extracts the environment and applies the function to it let clos = (f 3) in (#1 clos) (4,#2 clos) clos : int -> intclos : (int*int -> int) * int f  x:int. y:int. x + y

27. ICFP '98 Existential Types Unfortunately, the type of the closure now depends on its free variables Existential types hold the types of free variables abstract l1: x:int. pack (l2,x) as  env.((int*env -> int)*env) hiding int unpack (env,clos) = (f 3) in (#1 clos)(4,#2 clos) clos : (int*int -> int) * int

28. ICFP '98 Polymorphic Closure Conversion In a type passing semantics a function may also have free type variables at run time They also must be part of the closure, via translucent types The type environment is then abstracted using existential kinds  a. x:a.  y:int.... l1:  a. x:a.  (b=a).(l2[b], x) l2:  b. y:int,x:b.... clos :  k.  b:T.  a:k.  g:k = a. (int * b) -> int * b

29. ICFP '98 Closure Conversion In a type erasure semantics, only the type representation remains at run time. At the time of closure creation, the type arguments may be given to the function.  a. x:a, z:R(a). y:int.... l1:  a.  x:a,z:R(a). pack (l2[a], z) as  b.(int*b -> int)*b hiding (a*R(a)) l2:  b. y:int,(x:b,z:R(b))....

30. ICFP '98 Multi-stage Type Analysis Typed Assembly Language Typed Intermediate Language Typed Abstract Syntax Final Step of typed compilation: compile to a typed assembly language Implicitly Typed Source Language

31. ICFP '98 Multi-stage Type Analysis How do we preserve the meaning of typecase when the types themselves change? –in TALx86 both int and float are compiled into B4, the type of 4-byte values – int  int may be compiled into a variety of types depending on the calling convention

32. ICFP '98 06/08/9 9 Related Work Harper, Morrisett - POPL 95 Minamide, Morrisett, Harper - POPL 96 Minamide - 2nd Fuji Intl Workshop on Functional and Logic Programming 96 Morrisett, Walker, Crary, Glew - POPL 98 Crary, Weirich, Morrisett - ICFP 98 Crary, Weirich - ICFP 99

33. ICFP '98 Low-level Type Analysis How do we analyze types with quantifiers? –In TALx86 every function (polymorphic or not) is compiled into a polymorphic code pointer

34. ICFP '98 06/08/9 9 34 Areas for Future Work

35. ICFP '98

36. Outline Introduction –Typed Compilation –Type Analysis in general toString example –Type Analysis in compilation bit array example Initial framework –syntax -- from examples –semantics type passing –problems –complication of theory –can’t express efficient code –loss of abstraction Type erasure semantics syntax dynamic semantics static semantics Closure Conversion example LX Teaser Related work

37. ICFP '98 A note about typechecking –In this example wordsub has a strange type a array * int -> int –It would better if it were of type int array * int -> int –Then argument to subscript must allways be an int array. But that forgets its actual type of bool array. So we create a special type, called packed array, with a type-level type analysis operator.

38. ICFP '98 06/08/9 9 12ICFP '98 Type Passing Semantics sub[int](A,3)

39. ICFP '98 06/08/9 9 13 Type Passing Semantics ( . (A:  array,i:int). typecase  of int => wordsub(A,3) bool => (wordsub(A,3 div 32) & (1 0) [int] (A,3) sub[int](A,3)

40. ICFP '98 06/08/9 9 14 Type Passing Semantics ( . (A:  array,i:int). typecase  of int => wordsub(A,3) bool => (wordsub(A,3 div 32) & (1 0) [int] (A,3) sub[int](A,3) typecase int of int => wordsub(A,3) bool => (wordsub(A,3 div 32) & (1 0

41. ICFP '98 06/08/9 9 30 Formalization Special representation terms: –R int –R  (x,y)

42. ICFP '98 06/08/9 9 31 Formalization Special representation terms: –R int –R  (x,y) A term e which represents a type  has the special type R(  ). –R  (R int, R int ) : R(int  int)

43. ICFP '98 06/08/9 9 24 Type Erasure Semantics ( . x:R(  ). (A:  array,i:int). typecase x of Rint => wordsub(A,3) Rbool => (wordsub(A,3 div 32) & (1 0) [int] Rint (A,3) sub [int] Rint (A,3)

44. ICFP '98 06/08/9 9 25 Type Erasure Semantics ( . x:R(  ). (A:  array,i:int). typecase x of Rint => wordsub(A,3) Rbool => (wordsub(A,3 div 32) & (1 0) [int] Rint (A,3) sub [int] Rint (A,3) typecase Rint of Rint => wordsub(A,3) Rbool => (wordsub(A,3 div 32) & (1 0

45. ICFP '98

46. 06/08/9 9 5ICFP '98 Type based compilation TermsTypes Source Language Intermediate Language Machine Language

47. ICFP '98 Multi-stage Type Analysis

48. ICFP '98 Type Level Type Analysis

49. ICFP '98 Type Safe Language Give us guarentees about the run-time behavior of programs Types abstractly describe the run-time flow of values

50. ICFP '98 Traditional Compilation ( fn x => x+1 ) 3 ( x. x + 1 ) 3 l1: push 3 call l2 retn l2: mov eax,[esp+4] add eax,eax mov [esp+4], eax retn ( fn x : int => x +1 ) 3 Source File Type Inference Checking Untyped IL Machine Code

51. ICFP '98 Type Based Compilation ( fn x => x+1 ) 3 ( x : int. x + 1 ) 3 l1: push 3 call l2 retn l2: mov eax,[esp+4] add eax,eax mov [esp+4], eax retn ( fn x : int => x +1 ) 3 Source File Type Inference Checking Typed IL Machine Code

52. ICFP '98 Why Typed Compilation Safety -- assurances about compiler correctness Type based optimizations For example...

53. ICFP '98 But we don’t always know the types, what then ? For example -- Parametric polymorphism Introduce an operator into the language that can distinguish types Typecase !

54. ICFP '98 Need a language with this operator - lmli

55. ICFP '98 Second example print

56. ICFP '98 06/08/9 9 16ICFP '98 Performance and Safety TermsTypes Source IL Machine

57. ICFP '98 06/08/9 9 17ICFP '98 Safety Safety TermsTypes Source IL Machine TAL

58. ICFP '98 06/08/9 9 11ICFP '98 Type Passing Semantics Used by the language  i ML, the Intermediate language of TIL/ML and FLINT compilers Unlike most calculi where types may be erased prior to run-time, types do have an operational significance -- they are arguments to typecase terms.

59. ICFP '98 06/08/9 9 10ICFP '98 Intensional Type Analysis Valuable element of type-directed compilers Allows otherwise untypeable optimizations –Specialized data layout –Tag-free Garbage Collection –Polymorphic marshalling –...

60. ICFP '98 06/08/9 9 29 Solution More efficient –Only pass type representations when necessary –Traditional code optimizers can help –Sophisticated techniques still possible Recovers abstraction –Can withhold representation from clients