A Verified Compiler from Isabelle/HOL to CakeML

Transcript

1. A Verified Compiler from Isabelle/HOL to CakeML Lars Hupel Technische Universität München February 19th, 2018
2. Isabelle 2
3. Isabelle ▶ interactive proof assistant ▶ powerful automation ▶ classical and equational reasoning ▶ decision procedures (e.g. linear arithmetic) ▶ integration with external automated theorem provers ▶ ... ▶ supports functional programming 3
4. Low-level Isabelle ▶ generic proof assistant ▶ supports multiple object logics ▶ kernel: intuitionistic higher-order logic with natural deduction ▶ Isabelle/HOL built on top of the kernel ▶ ML code can be embedded almost everywhere ▶ theory syntax (commands) and term syntax (logic) can be extended 4
5. If you want to make an apple pie from scratch ... 5
6. Isabelle/HOL for Users People say Isabelle and mean Isabelle/HOL. ▶ inductive predicates ▶ datatypes and “refinement” types ▶ recursive functions ▶ pattern matching ▶ type classes 6
7. Isabelle/HOL for Users People say Isabelle and mean Isabelle/HOL. ▶ inductive predicates ▶ datatypes and “refinement” types ▶ recursive functions ▶ pattern matching ▶ type classes actually a feature of the kernel 6
8. Defining Datatypes datatype α list = Nil | Cons α (α list) This specification introduces: ▶ an induction principle ▶ a recursor rec_list :: α ⇒ (β ⇒ β list ⇒ α ⇒ α) ⇒ β list ⇒ α ▶ injective, non-overlapping constructors 7
9. Defining Datatypes datatype α list = Nil | Cons α (α list) This specification introduces: ▶ an induction principle ▶ a recursor rec_list :: α ⇒ (β ⇒ β list ⇒ α ⇒ α) ⇒ β list ⇒ α ▶ injective, non-overlapping constructors “freely constructed” 7
10. Defining Datatypes datatype α list = Nil | Cons α (α list) This specification introduces: ▶ an induction principle ▶ a recursor rec_list :: α ⇒ (β ⇒ β list ⇒ α ⇒ α) ⇒ β list ⇒ α ▶ injective, non-overlapping constructors ▶ alotmore “freely constructed” 7
11. Defining Functions ▶ HOL has a definition principle: x = λy1 . . . yn. t ▶ introduces a new constant and an axiom 8
12. Defining Functions ▶ HOL has a definition principle: x = λy1 . . . yn. t ▶ introduces a new constant and an axiom t must not depend on x itself 8
13. Defining Functions ▶ HOL has a definition principle: x = λy1 . . . yn. t ▶ introduces a new constant and an axiom ▶ primrec defines a function using a recursor t must not depend on x itself 8
14. Defining Functions ▶ HOL has a definition principle: x = λy1 . . . yn. t ▶ introduces a new constant and an axiom ▶ primrec defines a function using a recursor t must not depend on x itself “expressible as a fold” 8
15. Defining Functions ▶ HOL has a definition principle: x = λy1 . . . yn. t ▶ introduces a new constant and an axiom ▶ primrec defines a function using a recursor ▶ fun allows more flexible recursion, but need to prove termination t must not depend on x itself “expressible as a fold” 8
16. Functional Programming in Isabelle Definitions datatype α list = Nil | Cons α (α list) primrec append where append Nil ys = ys append (Cons x xs) ys = Cons x (append xs ys) 9
17. Functional Programming in Isabelle Definitions datatype α list = Nil | Cons α (α list) primrec append where append Nil ys = ys append (Cons x xs) ys = Cons x (append xs ys) Proofs lemma append xs (append ys zs) = append (append xs ys) zs by (induction xs) simp+ 9
18. Functional Programming in Isabelle Definitions datatype α list = Nil | Cons α (α list) fun append where append Nil ys = ys append (Cons x xs) ys = Cons x (append xs ys) Proofs lemma append xs (append ys zs) = append (append xs ys) zs by (induction xs) simp+ 9
19. Advanced Functional Programming Automatic termination proof fun fib where fib 0 = 1 fib (Suc 0) = 1 fib (Suc (Suc n)) = fib n + fib (Suc n) 10
20. Advanced Functional Programming Automatic termination proof fun fib where fib 0 = 1 fib (Suc 0) = 1 fib (Suc (Suc n)) = fib n + fib (Suc n) Manual termination proof function f91 where f91 n = (if 100 < n then n − 10 else f91 (f91 (n + 11))) 10
21. Evaluating Expressions We want to evaluate functions for concrete inputs, e.g. fib 10. 1. using term rewriting (by simp) ▶ certified, but slow 2. using code generation (by eval) ▶ fast, but not certified 11
22. Evaluating Expressions We want to evaluate functions for concrete inputs, e.g. fib 10. 1. using term rewriting (by simp) ▶ certified, but slow 2. using code generation (by eval) ▶ fast, but not certified 11
23. Code Generation Isabelle can generate code for ML, Haskell, Scala and OCaml ML datatype ’a list = Nil | Cons of ’a * ’a list; fun append Nil xs = xs | append (Cons (y, ys)) xs = Cons (y, append ys xs); 12
24. Code Generation Isabelle can generate code for ML, Haskell, Scala and OCaml Scala abstract sealed class list[A] final case class Nila[A]() extends list[A] final case class Cons[A](a: A, b: list[A]) extends list[A] def append[A](x0: list[A], xs: list[A]): list[A] = (x0, xs) match { case (Nila(), xs) => xs case (Cons(y, ys), xs) => Cons[A](y, append[A](ys, xs)) } 12
25. Code Generation Pipeline 1. input: Set of equations 2. preprocess 3. build dependency graph, compute SCCs 4. translate to intermediate language 5. serialize to target language 6. output: Source text 13
26. Certifying Code Generation Idea: Transform equations into intermediate formal object Intermediate AST is a value in the logic 14
27. Certifying Code Generation Idea: Transform equations into intermediate formal object Intermediate AST is a value in the logic Magnus O. Myreen and Scott Owens. Proof-producing synthesis of ML from higher-order logic. ICFP 2012. Magnus O. Myreen and Scott Owens. Proof-producing translation of higher-order logic into pure and stateful ML. JAR 2014. 14
28. Certifying Code Generation Approach by Myreen & Owens ▶ define a datatype for ML syntax, formalize semantics ▶ define relators between HOL values and ML values, e.g. relint :: ML_val ⇒ int ⇒ bool ▶ when code generator is invoked on constant f, ▶ define a logical constant fML containing the AST ▶ prove theorem relating f to fML using the type’s relator 15
29. Certifying Code Generation Approach by Myreen & Owens ▶ define a datatype for ML syntax, formalize semantics ▶ define relators between HOL values and ML values, e.g. relint :: ML_val ⇒ int ⇒ bool ▶ when code generator is invoked on constant f, ▶ define a logical constant fML containing the AST ▶ prove theorem relating f to fML using the type’s relator specified in Lem 15
30. Certified Code Generation Our Approach Stage 1 (certifying) ▶ define a higher-order lambda calculus with term-rewriting semantics ▶ define relators between HOL values and lambda terms, e.g. relint :: term ⇒ int ⇒ bool ▶ when code generator is invoked on constant f, ▶ define a logical constant fλ containing the TRS ▶ prove theorem relating f to fλ using the type’s relator 16
31. Certified Code Generation Our Approach Stage 1 (certifying) ▶ define a higher-order lambda calculus with term-rewriting semantics ▶ define relators between HOL values and lambda terms, e.g. relint :: term ⇒ int ⇒ bool ▶ when code generator is invoked on constant f, ▶ define a logical constant fλ containing the TRS ▶ prove theorem relating f to fλ using the type’s relator λ-terms are conceptually much simpler! 16
32. Certified Code Generation Our Approach Stage 1 (certifying) ▶ define a higher-order lambda calculus with term-rewriting semantics ▶ define relators between HOL values and lambda terms, e.g. relint :: term ⇒ int ⇒ bool ▶ when code generator is invoked on constant f, ▶ define a logical constant fλ containing the TRS ▶ prove theorem relating f to fλ using the type’s relator λ-terms are conceptually much simpler! requires type class elimination 16
33. Certified Code Generation Our Approach Stage 2 (certified) ▶ reuse ML syntax and semantics 16
34. Certified Code Generation Our Approach Stage 2 (certified) ▶ reuse ML syntax and semantics export Lem to Isabelle 16
35. Certified Code Generation Our Approach Stage 2 (certified) ▶ reuse ML syntax and semantics ▶ define a HOL function compile :: (term × term) set ⇒ ML_val ▶ prove it correct once and for all export Lem to Isabelle 16
36. Challenges ▶ Isabelle supports type classes, ML doesn’t certifying dictionary construction ▶ users can specify custom equations need to figure out termination and induction principles (like fun) ▶ generation of relators for complex data types complex proof tactics to accomodate for non-standard recursion ▶ set of code equations is unordered need to specify wellformedness conditions ▶ transformation from term rewriting to big-step semantics multiple compiler phases 17
37. Challenge: Custom Code Equations What the user specified sum_by f = sum ◦ map f 18
38. Challenge: Custom Code Equations What the user specified sum_by f = sum ◦ map f What the user proved sum_by f [] = 0 sum_by f (x # xs) = f x + sum_by xs 18
39. Challenge: Custom Code Equations What the user specified sum_by f = sum ◦ map f What the user proved sum_by f [] = 0 sum_by f (x # xs) = f x + sum_by xs What the system needs sum_by monoidβ f [] = zero monoidβ sum_by monoidβ f (x # xs) = plus monoidβ (f x) (sum_by monoidβ f xs) 18
40. Challenge: Term Rewriting to Big-Step de Bruijn terms Named bound variables Explicit pattern matching R :: (term × term) set, t, t′ :: term R ⊢ t −→ t′ R :: (term × nterm) set, t, t′ :: nterm R ⊢ t −→ t′ R :: (string × pterm) set, t, t′ :: pterm R ⊢ t −→ t′ 19 compiler phase semantics refinement semantics belonging to the phase
41. Challenge: Term Rewriting to Big-Step Explicit pattern matching Sequential clauses R :: (string × pterm) set, t, t′ :: pterm R ⊢ t −→ t′ rs :: (string × sterm) list, t, t′ :: sterm rs ⊢ t −→ t′ rs :: (string×sterm) list, σ :: string ⇀ sterm t, u :: sterm rs, σ ⊢ t ↓ u 19 compiler phase semantics refinement semantics belonging to the phase
42. Challenge: Term Rewriting to Big-Step Sequential clauses Evaluation semantics rs :: (string×sterm) list, σ :: string ⇀ sterm t, u :: sterm rs, σ ⊢ t ↓ u rs :: (string × value) list, σ :: string ⇀ value t :: sterm, u :: value rs, σ ⊢ t ↓ u σ :: string ⇀ value t :: sterm, u :: value σ ⊢ t ↓ u 19 compiler phase semantics refinement semantics belonging to the phase
43. Key Insights ▶ reusable Lem specifications are a game changer ▶ less certifying code, more certified proofs ▶ feature parity is challenging ▶ performance is a significant issue 20
44. Q & A  lars.hupel.info  larsrh  larsr_h