Type-Driven Development of Certified Tree of Certified Tree - PowerPoint PPT Presentation

Type-Driven Development Type-Driven Development of Certified Tree of Certified Tree Algorithms Algorithms An Experience Report on Dependently-Typed Programming Introduction in Coq Initial take Why dependent types? Reynald Affeldt 1 Jacques Garrigue 2,4 Producing better code Xuanrui Qi 2,3 Kazunari Tanaka 2 Conclusion 1 National Institute of Advanced Industrial Science and Technology, Japan 2 Graduate School of Mathematics, Nagoya University, Japan 3 Department of Computer Science, Tufts University, USA 4 Inria Paris, France September 8, 2019 The Coq Workshop 2019, Portland, Oregon 1 / 22

Type-Driven Development Our story of Certified Tree Algorithms Introduction Initial take Dependently-typed Programming in Coq: Why and How? Why dependent types? The “Why” Why did we use dependent types in Coq? Under Producing better code what occasions are they useful? Conclusion The “How” What is the best approach towards dependently-typed programming in Coq? How did we approach it? 2 / 22

Type-Driven Development Our story of Certified Tree Algorithms Introduction Initial take Dependently-typed Programming in Coq: Why and How? Why dependent types? The “Why” Why did we use dependent types in Coq? Under Producing better code what occasions are they useful? Conclusion The “How” What is the best approach towards dependently-typed programming in Coq? How did we approach it? 2 / 22

Type-Driven Development Our story of Certified Tree Algorithms Introduction Initial take Dependently-typed Programming in Coq: Why and How? Why dependent types? The “Why” Why did we use dependent types in Coq? Under Producing better code what occasions are they useful? Conclusion The “How” What is the best approach towards dependently-typed programming in Coq? How did we approach it? 2 / 22

Type-Driven Development Quick recap: what were we of Certified Tree Algorithms working on? Bit vectors with efficient insert & delete: Introduction Initial take delete 2 nd bit Why dependent types? Producing better code Conclusion 100 10101 1111 101 1111 • Represented using a red-black tree • Insertion and deletion might involve inserting/deleting nodes 3 / 22

Type-Driven Development The motivation of Certified Tree Algorithms Introduction Initial take Deletion from red-black trees is too hard. Why dependent types? • long standing problem with a few proposed solutions Producing better code [Kahrs 2001; Germane & Might 2014], but none of them Conclusion totally satisfactory for us; • complex invariant hard to describe precisely • difficult to transcribe to our non-standard tree structure (bit-borrowing, leaf merging, etc.) 4 / 22

Type-Driven Development Take 1 of Certified Tree Algorithms Introduction We tried transcribing Kahrs’ Haskell code directly to Coq Initial take without trying to fully understand it. But you guessed... Why dependent types? Producing better code Conclusion 5 / 22

Type-Driven Development Take 1 of Certified Tree Algorithms Introduction We tried transcribing Kahrs’ Haskell code directly to Coq Initial take without trying to fully understand it. But you guessed... Why dependent types? Producing better code Conclusion 5 / 22

Type-Driven Development Using dependent types of Certified Tree Algorithms Introduction Initial take Problem: Why • not sure about how to do case analysis; dependent types? • not sure about the exact invariants; Producing better code • not sure about the auxiliary structures required. Conclusion Idea : use dependently-typed programming to guide programming process. 6 / 22

Type-Driven Development Auxiliary structures? of Certified Tree Algorithms The intermediate data structures required for re-balancing the Introduction tree: Initial take Inductive near_tree : nat -> nat -> nat -> Why dependent color -> Type := types? | Bad : forall {s1 o1 s2 o2 s3 o3 d}, Producing better code tree s1 o1 d Black -> Conclusion tree s2 o2 d Black -> tree s3 o3 d Black -> near_tree (s1 + s2 + s3) (o1 + o2 + o3) d Red | Good: forall {s o d c} p, tree s o d c -> near_tree s o d p. Re-balancing requires temporarily breaking the red-black tree invariants, hence the need for auxiliary structures. 7 / 22

Type-Driven Development Auxiliary structures? of Certified Tree Algorithms The intermediate data structures required for re-balancing the Introduction tree: Initial take Inductive near_tree : nat -> nat -> nat -> Why dependent color -> Type := types? | Bad : forall {s1 o1 s2 o2 s3 o3 d}, Producing better code tree s1 o1 d Black -> Conclusion tree s2 o2 d Black -> tree s3 o3 d Black -> near_tree (s1 + s2 + s3) (o1 + o2 + o3) d Red | Good: forall {s o d c} p, tree s o d c -> near_tree s o d p. Re-balancing requires temporarily breaking the red-black tree invariants, hence the need for auxiliary structures. 7 / 22

Type-Driven Development Take 2: Ltac of Certified Tree Algorithms Introduction Initial take Why • use tactics to develop the program dependent types? • we ascribe strict types to each function, allowing to be Producing better code completely sure that our code is correct Conclusion • as a side effect, we got a very clean specification • no “external” lemmas which can be easy to forget • all desired invariants were encoded into the types 8 / 22

Type-Driven Development Take 2: Ltac of Certified Tree Algorithms Introduction Initial take Why • use tactics to develop the program dependent types? • we ascribe strict types to each function, allowing to be Producing better code completely sure that our code is correct Conclusion • as a side effect, we got a very clean specification • no “external” lemmas which can be easy to forget • all desired invariants were encoded into the types 8 / 22

Type-Driven Development Programming Coq with tactics of Certified Tree Algorithms Introduction Initial take Why dependent The Pros types? • “No brainer”: no need to fully understand the algorithm Producing better code [Chlipala 2013] Conclusion • Easy to refactor: when underlying data structures change • Quick fixes & adapting to changes 9 / 22

Type-Driven Development Programming Coq with tactics of Certified Tree Algorithms Introduction Initial take Why dependent types? The Cons Producing • You don’t know what you’re actually doing better code • Readability: other people don’t know what you’re doing Conclusion • Semantics of Ltac changes frequently 10 / 22

Type-Driven Development Type-driven development? of Certified Tree Algorithms Introduction “Type-driven” in what sense? Initial take Why dependent Regular development: design the algorithm, and then write types? types to check that you’re correct. Producing better code Conclusion Type-driven development : write types to declare what you want, and then code until it type checks It type checks, ship it! 11 / 22

Type-Driven Development Type-driven development? of Certified Tree Algorithms Introduction “Type-driven” in what sense? Initial take Why dependent Regular development: design the algorithm, and then write types? types to check that you’re correct. Producing better code Conclusion Type-driven development : write types to declare what you want, and then code until it type checks It type checks, ship it! 11 / 22

Type-Driven Development Type-driven development? of Certified Tree Algorithms Introduction “Type-driven” in what sense? Initial take Why dependent Regular development: design the algorithm, and then write types? types to check that you’re correct. Producing better code Conclusion Type-driven development : write types to declare what you want, and then code until it type checks It type checks, ship it! 11 / 22

Type-Driven Development Type-driven development? of Certified Tree Algorithms Introduction “Type-driven” in what sense? Initial take Why dependent Regular development: design the algorithm, and then write types? types to check that you’re correct. Producing better code Conclusion Type-driven development : write types to declare what you want, and then code until it type checks It type checks, ship it! 11 / 22

Type-Driven Development Applying the TDD methodology of Certified Tree Algorithms Introduction At first, we had no clue about what the delete algorithm should Initial take look like! Why dependent types? We began with a complete specification: Producing better code Definition ddelete Conclusion (d: nat) (c: color) (num ones : nat) (i : nat) (B : tree w num ones (incr_black d c) c) : { B' : tree (num - (i < num)) (ones - (daccess B i)) d c | dflatten B' = delete (dflatten B) i }. 12 / 22

Type-Driven Development Applying the TDD methodology of Certified Tree Algorithms Introduction At first, we had no clue about what the delete algorithm should Initial take look like! Why dependent types? We began with a complete specification: Producing better code Definition ddelete Conclusion (d: nat) (c: color) (num ones : nat) (i : nat) (B : tree w num ones (incr_black d c) c) : { B' : tree (num - (i < num)) (ones - (daccess B i)) d c | dflatten B' = delete (dflatten B) i }. 12 / 22