1. Lambda: The Ultimate Specification a talk/demo on Fiat, a Coq library for program synthesis Adam Chlipala IFIP WG 2.18 meeting August 2014 Joint work with Benjamin Delaware, Clément Pit—Claudel, and Jason Gross

2. 2 Functional Programming & World Domination Years # of ICFP corporate sponsors

3. 3 Functional Programming & World Domination Years # of ICFP corporate sponsors Coq Workshop corporate sponsors

4. 4 We won! First-class functions! Garbage collection! Etc.

5. 5 Program (explains how to evolve state) state Optimizing compiler (finds equivalent but cheaper trajectories) The bad old days: imperative codeBetter: functional code Program Optimizing compiler (finds equivalent but cheaper trajectories) Commonality #1: To achieve good performance, programs must be written with some sort of operational model in mind. Commonality #2: Monolithic compiler that mere mortals fear to touch.

6. 6 What are popular ways of freeing programmers from bothering with operational models of performance? SELECT COUNT(*) FROM books, orders WHERE books.ISBN = authors.ISBN AND books.Author = “John Doe” Relational databases! How many orders for books by John Doe? ☺ Reasoning about code independently of operational performance model ☹ SQL query planner is black magic; hands off!

7. 7 Program Modularity, Sliced Differently IDEA algorithm data structure IDEA functional behavior optimizations Only need to read this part of the code, to understand non-performance aspects! Language implementation should enforce that optimizations can't break correctness. Language implementation should enforce that algorithms can't break data structure invariants.

8. 8 Fiat: A Program Derivation Framework in Coq Program synthesis by stepwise refinement 1. Write mathematical specifications without worrying about performance. 2. Apply optimization scripts to refine specifications into efficient programs. 3. Coq's usual proof checker validates that scripts have preserved semantics. Big delta from past related work: “high automation without giving up high assurance”

9. 9 Step 1: Specification query "NumOrders" (author : string) : nat := Count (For (o in “Orders”) (b in “Books”) Where (author = b!”Author”) Where (b!”ISBN” = o!”ISBN”) Return ()) Notes: ● Example of an SQL-style query ● Similar to monadic query comprehension notation. ● Parsed & type-checked within normal Coq code (extensible parser, etc.)

10. 10 Step 2: Optimization Script Definition BookStorage : IndexFor Book. mkIndex [ BookSchema/sAUTHOR; BookSchema/sISBN ]. Defined. Definition OrderStorage : IndexFor Order. mkIndex [ OrderSchema/sISBN ]. Defined. Choose data structures: Definition Bookstore_AbsR := … Define abstraction relation connecting them to specification: plan Bookstore_AbsR. Call library tactic to implement specs in terms of this relation:

11. 11 Step 3: Reasonable Code! meth “NumOrders” (p : rep, s : string) : nat := ret (p, fold_left (fun (count : nat) (x : Tuple) => count + bcount (snd p) (Some x!”ISBN”, [])) (bfind (fst p) (Some s, (None, []))) 0) Calls to methods of library data structures (nested AVL trees)

12. 12 Design Principle #1: Nondeterminism Monad Comp a = a -> Prop -- powerset of a return :: a -> Comp a return x = {x} bind :: Comp a -> (a -> Comp b) -> Comp b bind c1 c2 = {y | ∃ x ∈ c1. y ∈ c2(x)} The subset relation serves naturally as a notion of “implements”! E.g.: do { n ← {x | P(x)}; return (2 * n) } ⊆ {x | even(x)}

13. 13 Design Principle #2: Rewriting in Computations ⊆ is a preorder and has the right congruences with useful operators: c1 ⊆ c1' ⇒ bind c1 c2 ⊆ bind c1' c2 ( ∀ x. c2(x) ⊆ c2'(x)) ⇒ bind c1 c2 ⊆ bind c1 c2' Therefore, we can consider ⊆ facts as oriented rewrite rules, e.g.: Use: {x | Q(x)} ⊆ {x | P(x)} to switch in one step from showing: do { n ← {x | P(x)}; return (2 * n) } ⊆ … to showing: do { n ← {x | Q(x)}; return (2 * n) } ⊆ …

14. 14 Design Principle #3: Abstract Data Types Interfaces: Methods with types like: rep × A rep × B “rep” is a placeholder for internal representation type. Implementations: Concrete representation type One Comp-function per method When does one implementation refine another? Write I v J for: There exists an abstraction relation “ ≃ ” between the two rep. types. ∀ m, r1, r2. r1 ≃ r2 ⇒ ∀ i, r2', o. (r2', o) ∈ J.m(r2, i) ⇒ ∃ r1'. (r1', o) ∈ I.m(r, i) ∧ r1' ≃ r2' r1 r2 ≃ r1' r2' ≃ I.m J. m

15. 15 A Neat Maneuver Have: ADT { rep = rep1 … method m(r : rep, x : A) : rep × B = f(r, x) … } Given an abstraction relation ≃ relating rep1 to rep2, can always transform like so: ADT { rep = rep2 … method m(r1 : rep, x : A) : rep × B = {(r1', o) | ∀ r2. r1 ≃ r2 ⇒ ∃ r2'. (r2', o) ∈ f(r2, i) ∧ r1' ≃ r2'} … }

16. 16 Demo!