1 Dependent Types for Termination Verification Hongwei Xi University of Cincinnati

2 Overview Motivation Program error detection at compile-time Compilation certification Termination Verification for Dependent ML Theoretical development Practical applications Conclusion

3 Program Error Detection Unfortunately one often pays a price for [languages which impose no disciplines of types] in the time taken to find rather inscrutable bugs — anyone who mistakenly applies CDR to an atom in LISP and finds himself absurdly adding a property list to an integer, will know the symptoms. -- Robin Milner A Theory of Type Polymorphism in Programming Therefore, a stronger type discipline allows for capturing more program errors at compile-time.

4 Some Advantages of Types Detecting program errors at compile-time Enabling compiler optimizations Facilitating program verification Using types to encode program properties Verifying the encoded properties through type- checking Serving as program documentation Unlike informal comments, types are formally verified and can thus be fully trusted

5 Compiler Correctness How can we prove the correctness of a (realistic) compiler? Verifying that the semantics of e is the same as the semantics of |e| for every program e But this simply seems too challenging (and is unlikely to be feasible) Source program e Target code | e | compilation |. ||. |

6 Compilation Certification Assume that  e  holds, i.e., e has the property  Then  e  should hold, too A compiler can be designed to produce a certificate to assert that  e  does have the property  Target code  e  :  e  holds Source program e:  e  holds compilation |. ||. |

7 Narrowing the Gap NuPrl Coq Program Extraction Proof Synthesis ML Dependent ML

8 Termination Verification Termination is a liveness property can not be verified at run-time is often proven with a well-founded metric that decreases whenever a recursive function call is made

9 Primitive Recursion datatype Nat with nat = Z(0) | {n:nat} S(n+1) of Nat(n) (* Z: Nat(0) S: {n:nat} Nat(n) -> Nat(n+1) *) fun (‘a) R Z u v = u | R (S n) u v = v n (R n u v) withtype {n:nat} Nat(n) -> ‘a -> (Nat -> ‘a -> ‘a) -> ‘a (* Nat is for [n:nat] Nat(n) *) =>

10 Ackermann Function in DML fun ack (m, n) = if m = 0 then n+1 else if n = 0 then ack (m-1, 1) else ack (m-1, ack (m, n-1)) withtype {m:nat,n:nat} int(m) * int(n) -> nat (* Note: nat = [a:int | a >=0] int(a) *) =>

11 What’s really new here? We present a formalism that allows the programmer to supply crucial information for facilitating program termination verification can smoothly integrate into a realistic programming language

12 ML 0: start point base types  ::= int | bool | (user defined datatypes) types  ::=  |       |      patterns p ::= x | c(p) | <> | match clauses ms ::= (p  e) | (p  e | ms) expressions e ::= x | f | c | if (e, e 1, e 2 ) | <> | | lam x: . e | fix f: . e | e 1 (e 2 ) | let x=e 1 in e 2 end | case e of ms values v ::= x | c | | lam x: . e context  ::=. | , x: 

13 Integer Constraint Domain We use a for index variables index expressions i, j ::= a | c | i + j | i – j | i * j | i / j | … index propositions P, Q ::= i j | i >= j | i = j | i <> j | P  Q | P  Q index sorts  ::= int | {a :  | P } index variable contexts  ::=. | , a:  | , P index constraints  ::= P | P   |  a:  

14 Dependent Types dependent types  ::=... |  (i) |  a: .  |  a: .  For instance, int(0), bool array(16); nat = [a:int | a >= 0] int(a); {a:int | a >= 0} int list(a) -> int list(a)

15 DML 0  ML 0 + dependent types expressions e ::=... | a: .v | e[i] | | open e 1 as in e 2 end values v ::=... | a: .v | typing judgment  e 

16 A Typing Rule  e  bool(i)  i  e 1:  i  e 2:   type-if   if (e, e 1, e 2 ): 

17 Metric Typing Judgments Definition (Metric) Let  = be a tuple of index expressions. We write   : metric if we have  i j :nat for 1  j  n. We use  a  for a decorated type We use the judgemnt  e  f    to mean that for each occurrence of f[i] in e,  [a->i]    holds, where f is declared in  to have type  a 

18 Some Metric Typing Rules  The rule (  app) is:  e 1      f    e 2    f      e 1( e 2):      f    The rule (  lab) is:  i  a  i    f  a     f  i  a  i  f  

19 DML 0,  The following typing rule is for forming functions:  a  f  a  |- e:   f   type-fun)   fun f  a  is e:  a 

20 Reducibility Definition Suppose that e is a closed expression of type  and e  * v holds for some value v.   is a base type. Then e is reducible          Then e is reducible if e(v 1 ) is reducible for every reducible value v 1 of type  .       Then e is reducible if v= and v 1, v 2 are reducible.     a: .    Then e is reducible if e[i] is reducible for every i: .     a: .    Then e is reducible if v= and v 1 is reducible.

21  -reducibility Definition Let e be a well-typed closed function fun f[a:  ]:  is v and   be a closed metric. e is   -reducible if e[i] is reducible for each i  satisfying  [a->i]   . Theorem Every closed expression e is reducible if it is well-typed in DML 0, 

22 Quicksort in DML fun qs [] = [] | qs (x :: xs) = par (x, xs, [], []) withtype {n:nat} int list(n) -> int list(n) and par (x, [], l, g) = qs (x :: qs (g)) | par (x, y :: ys, l, g) = if y <= x then par (x, ys, y :: l, g) else par (x, ys, l, y :: g) withtype {p:nat,q:nat,r:nat} int * int list(p) * int list(q) * int list(r) -> int list(p+q+r+1) =>

23 Contributions Novel type system design to facilitate termination verification Unobtrusive programming Theoretical foundation Prototype implementation and evaluation

24 Some Closely Related Work Termination and Reduction Checking in Logic Framework, Pientka and Pfenning Termination Analysis for Mercury, Speirs, Somogyi and S Ø ndergarrd Proving correctness of reactive systems using sized types, Hughes, Pareto and Sabry. Cost recurrences for DML programs, Bernd Grobauer.

25 End of the Talk Thank You! Questions?