DOCSLIB.ORG

Programs and Proofs Mechanizing Mathematics with Dependent Types

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Programs and Proofs Mechanizing Mathematics with Dependent Types Programs and Proofs Mechanizing Mathematics with Dependent Types Lecture Notes Ilya Sergey Draft of July 16, 2020 Contents Contents 1 1 Introduction5 1.1 Why yet another course on Coq?......................5 1.1.1 What this course is about......................7 1.1.2 What this course is not about....................7 1.1.3 Why Ssreflect?............................7 1.2 Prerequisites..................................8 1.3 Setup......................................9 1.3.1 Installing Coq, Ssreflect and Mathematical Components......9 1.3.2 Emacs set-up.............................9 1.3.3 Getting the lecture files and solutions................ 10 1.4 Naming conventions.............................. 10 1.5 Acknowledgements.............................. 11 2 Functional Programming in Coq 13 2.1 Enumeration datatypes............................ 13 2.2 Simple recursive datatypes and programs.................. 15 2.2.1 Dependent function types and pattern matching.......... 18 2.2.2 Recursion principle and non-inhabited types............ 20 2.3 More datatypes................................ 21 2.4 Searching for definitions and notations................... 24 2.5 An alternative syntax to define inductive datatypes............ 25 2.6 Sections and modules............................. 26 3 Propositional Logic 29 3.1 Propositions and the Prop sort....................... 29 3.2 The truth and the falsehood in Coq..................... 30 3.3 Implication and universal quantification................... 35 3.3.1 On forward and backward reasoning................ 37 3.3.2 Refining and bookkeeping assumptions............... 38 3.4 Conjunction and disjunction......................... 39 3.5 Proofs with negation............................. 42 3.6 Existential quantification........................... 43 3.6.1 A conjunction and disjunction analogy............... 45 3.7 Missing axioms from classical logic..................... 46 3.8 Universes and Prop impredicativity..................... 47 3.8.1 Exploring and debugging the universe hierarchy.......... 48 2 Contents 4 Equality and Rewriting Principles 53 4.1 Propositional equality in Coq........................ 53 4.1.1 Case analysis on an equality witness................ 54 4.1.2 Implementing discrimination..................... 55 4.1.3 Reasoning with Coq’s standard equality.............. 57 4.2 Proofs by rewriting.............................. 57 4.2.1 Unfolding definitions and in-place rewritings............ 57 4.2.2 Proofs by congruence and rewritings by lemmas.......... 58 4.2.3 Naming in subgoals and optional rewritings............ 60 4.2.4 Selective occurrence rewritings.................... 61 4.3 Indexed datatype families as rewriting rules................ 62 4.3.1 Encoding custom rewriting rules................... 63 4.3.2 Using custom rewriting rules..................... 63 5 Views and Boolean Reflection 67 5.1 Proving with views in Ssreflect........................ 68 5.1.1 Combining views and bookkeeping................. 69 5.1.2 Using views with equivalences.................... 69 5.1.3 Declaring view hints......................... 70 5.1.4 Applying view lemmas to the goal.................. 70 5.2 Prop versus bool ............................... 71 5.2.1 Using conditionals in predicates................... 74 5.2.2 Case analysing on a boolean assumption.............. 74 5.3 The reflect type family............................ 75 5.3.1 Reflecting logical connectives.................... 76 5.3.2 Reflecting decidable equalities.................... 79 6 Inductive Reasoning in Ssreflect 81 6.1 Structuring the proof scripts......................... 81 6.1.1 Bullets and terminators....................... 81 6.1.2 Using selectors and discharging subgoals.............. 82 6.1.3 Iteration and alternatives...................... 82 6.2 Inductive predicates that should be functions................ 83 6.2.1 Eliminating assumptions with a custom induction hypothesis... 88 6.3 Inductive predicates that are hard to avoid................. 89 6.4 Working with Ssreflect libraries....................... 93 6.4.1 Notation and standard properties of algebraic operations..... 93 6.4.2 A library for lists........................... 94 7 Encoding Mathematical Structures 97 7.1 Encoding partial commutative monoids................... 98 7.1.1 Describing algebraic data structures via dependent records.... 99 7.1.2 An alternative definition....................... 101 7.1.3 Packaging the structure from mixins................ 101 7.2 Properties of partial commutative monoids................. 103 7.3 Implementing inheritance hierarchies.................... 104 Contents 3 7.4 Instantiation and canonical structures.................... 105 7.4.1 Defining arbitrary PCM instances.................. 105 7.4.2 Types with decidable equalities................... 109 8 Case Study: Program Verification in Hoare Type Theory 111 8.1 Imperative programs and their specifications............... 112 8.1.1 Specifying and verifying programs in a Hoare logic........ 113 8.1.2 Adequacy of a Hoare logic...................... 116 8.2 Basics of Separation Logic.......................... 117 8.2.1 Selected rules of Separation Logic.................. 119 8.2.2 Representing loops as recursive functions.............. 120 8.2.3 Verifying heap-manipulating programs............... 121 8.3 Specifying effectful computations using types................ 123 8.3.1 On monads and computations.................... 124 8.3.2 Monadic do-notation......................... 125 8.4 Elements of Hoare Type Theory....................... 126 8.4.1 The Hoare monad........................... 127 8.4.2 Structuring program verification in HTT.............. 128 8.4.3 Verifying the factorial procedure mechanically........... 130 8.5 On shallow and deep embeddings...................... 136 8.6 Soundness of Hoare Type Theory...................... 138 8.7 Specifying and verifying programs with linked lists............. 138 9 Conclusion 143 Bibliography 145 Index 151 1 Introduction These lecture notes are the result of the author’s personal experience of learning how to structure formal reasoning using the Coq proof assistant and employ Coq in large-scale research projects. The present manuscript offers a brief and practically-oriented intro- duction to the basic concepts of mechanized reasoning and interactive theorem proving. The primary audience of this text are the readers with expertise in software develop- ment and programming and knowledge of discrete mathematic disciplines on the level of an undergraduate university program. The high-level goal of the course is, therefore, to demonstrate how much the rigorous mathematical reasoning and development of ro- bust and intellectually manageable programs have in common, and how understanding of common programming language concepts provides a solid background for building math- ematical abstractions and proving theorems formally. The low-level goal of this course is to provide an overview of the Coq proof assistant, taken in its both incarnations: as an expressive functional programming language with dependent types and as a proof assistant providing support for mechanized interactive theorem proving. By aiming for these two goals, this manuscript is, thus, intended to provide a demon- stration how the concepts familiar from the mainstream programming languages and serving as parts of good programming practices can provide illuminating insights about the nature of reasoning in Coq’s logical foundations and make it possible to reduce the burden of mechanical theorem proving. These insights will eventually give the reader a freedom to focus solely on the essential part of her formal development instead of fighting with a proof assistant in futile attempts to encode the “obvious” mathematical intuition—a reason that made many of the new-comers abandon their attempts to apply the machine-assisted approach for formal reasoning as an everyday practice. 1.1 Why yet another course on Coq? The Coq proof assistant [10] has been in development since 1983, and by now there is a number of courses that provide excellent introductions into Coq-powered interactive theo- rem proving and software development. Among the other publicly available manuscripts, the author finds the following three to be the most suitable for teaching purposes. • The classical book Interactive Theorem Proving and Program Development. Coq’Art: The Calculus of Inductive Constructions by Yves Bertot and Pierre Castéran [3] is a great and exhaustive overview of Coq as a formal system and a tool, covering both logical foundations, reasoning methodologies, automation tools and offering large number of examples and exercises (from which this course borrows some). 6 1 Introduction • Benjamin Pierce et al.’s Software Foundations electronic book [53] introduces Coq development from an angle of the basic research in programming languages, focusing primarily on formalization of program language semantics and type systems, which serve both as main motivating examples of Coq usage and a source of intuition for explaining Coq’s logical foundations. • The most recently published book, Certified Programming with Dependent Types by Adam Chlipala [7] provides a gentle introduction to Coq from the perspective of writing programs that manipulate certificates, i.e., first-class proofs of the program’s correctness. The idea of certified programming is a natural fit for a programming language with dependent types, which Coq offers, and the book is structured as a series of examples that make the dependently-typed aspect
Load more

Recommended publications
  • Experience Implementing a Performant Category-Theory Library in Coq
    Experience Implementing a Performant Category-Theory Library in Coq Jason Gross, Adam Chlipala, and David I. Spivak Massachusetts Institute of Technology, Cambridge, MA, USA [email protected], [email protected], [email protected] Abstract. We describe our experience implementing a broad category- theory library in Coq. Category theory and computational performance are not usually mentioned in the same breath, but we have needed sub- stantial engineering effort to teach Coq to cope with large categorical constructions without slowing proof script processing unacceptably. In this paper, we share the lessons we have learned about how to repre- sent very abstract mathematical objects and arguments in Coq and how future proof assistants might be designed to better support such rea- soning. One particular encoding trick to which we draw attention al- lows category-theoretic arguments involving duality to be internalized in Coq's logic with definitional equality. Ours may be the largest Coq development to date that uses the relatively new Coq version developed by homotopy type theorists, and we reflect on which new features were especially helpful. Keywords: Coq · category theory · homotopy type theory · duality · performance 1 Introduction Category theory [36] is a popular all-encompassing mathematical formalism that casts familiar mathematical ideas from many domains in terms of a few unifying concepts. A category can be described as a directed graph plus algebraic laws stating equivalences between paths through the graph. Because of this spar- tan philosophical grounding, category theory is sometimes referred to in good humor as \formal abstract nonsense." Certainly the popular perception of cat- egory theory is quite far from pragmatic issues of implementation.
    [Show full text]
  • Exploring Languages with Interpreters and Functional Programming Chapter 8
    Exploring Languages with Interpreters and Functional Programming Chapter 8 H. Conrad Cunningham 24 September 2018 Contents 8 Evaluation Model 2 8.1 Chapter Introduction . .2 8.2 Referential Transparency Revisited . .2 8.3 Substitution Model . .3 8.4 Time and Space Complexity . .6 8.5 Termination . .7 8.6 What Next? . .7 8.7 Exercises . .8 8.8 Acknowledgements . .8 8.9 References . .9 8.10 Terms and Concepts . .9 Copyright (C) 2016, 2017, 2018, H. Conrad Cunningham Professor of Computer and Information Science University of Mississippi 211 Weir Hall P.O. Box 1848 University, MS 38677 (662) 915-5358 Browser Advisory: The HTML version of this textbook requires a browser that supports the display of MathML. A good choice as of September 2018 is a recent version of Firefox from Mozilla. 1 8 Evaluation Model 8.1 Chapter Introduction This chapter introduces an evaluation model applicable to Haskell programs. As in the previous chapters, this chapter focuses on use of first-order functions and primitive data types. A goal of this chapter and the next one is enable students to analyze Haskell functions to determine under what conditions they terminate normally and how efficient they are. This chapter presents the evaluation model and the next chapter informally analyzes simple functions in terms of time and space efficiency and termination. How can we evaluate (i.e. execute) an expression that “calls” a function like the fact1 function from Chapter 4? We do this by rewriting expressions using a substitution model, as we see in this chapter. This process depends upon a property of functional languages called referential transparency.
    [Show full text]
  • Week 3: Scope and Evaluation Order Assignment 1 Has Been Posted!
    Week 3: Scope and Evaluation Order CSC324 Principles of Programming Languages David Liu, Department of Computer Science Assignment 1 has been posted! Closures and static scope static (adjective) determined only by the program source code dynamic (adjective) determined only when the program is run E.g., referential transparency is a static property How are closures implemented? Are they static or dynamic? Or both? Function bodies can be processed statically (e.g., Haskell compiler generates code once per lambda). The closure environment (and therefore the closure itself) can only be generated dynamically. The closure depends only on where the function is evaluated, not where that function is called. (define (make-adder n) (lambda (x) (+ x n))) (define adder (make-adder 1)) (adder 100) So we can determine where each free identifier obtains its values statically, based on where its enclosing function is defined. scope (of an identifier) The parts of program code that may refer to that identifier. static (aka lexical) scope The scope of every identifier is determined by the structure of the source code (e.g., by nesting of lambdas and lets). Every identifier obtains its value from the closest enclosing expression that binds it. (define (make-adder n) (lambda (x) (+ x n))) (define adder (make-adder 1)) ; (0x..., {n: 1}) (let* ([n 100]) (adder 2)) Implementing static scope in an interpreter A simple interpreter (define/match (interpret env expr) [(_ (? number?)) expr] [(_ (? symbol?)) (hash-ref env expr)] [(_ (list '+ l r)) (+ (interpret env l) (interpret env r))]) A simple interpreter (define/match (interpret env expr) [(_ (? number?)) expr] [(_ (? symbol?)) (hash-ref env expr)] [(_ (list '+ l r)) (+ (interpret env l) (interpret env r))]) The environment is passed recursively when interpreting each subexpression.
    [Show full text]
  • Xcode Package from App Store
    KH Computational Physics- 2016 Introduction Setting up your computing environment Installation • MAC or Linux are the preferred operating system in this course on scientific computing. • Windows can be used, but the most important programs must be installed – python : There is a nice package ”Enthought Python Distribution” http://www.enthought.com/products/edudownload.php – C++ and Fortran compiler – BLAS&LAPACK for linear algebra – plotting program such as gnuplot Kristjan Haule, 2016 –1– KH Computational Physics- 2016 Introduction Software for this course: Essentials: • Python, and its packages in particular numpy, scipy, matplotlib • C++ compiler such as gcc • Text editor for coding (for example Emacs, Aquamacs, Enthought’s IDLE) • make to execute makefiles Highly Recommended: • Fortran compiler, such as gfortran or intel fortran • BLAS& LAPACK library for linear algebra (most likely provided by vendor) • open mp enabled fortran and C++ compiler Useful: • gnuplot for fast plotting. • gsl (Gnu scientific library) for implementation of various scientific algorithms. Kristjan Haule, 2016 –2– KH Computational Physics- 2016 Introduction Installation on MAC • Install Xcode package from App Store. • Install ‘‘Command Line Tools’’ from Apple’s software site. For Mavericks and lafter, open Xcode program, and choose from the menu Xcode -> Open Developer Tool -> More Developer Tools... You will be linked to the Apple page that allows you to access downloads for Xcode. You wil have to register as a developer (free). Search for the Xcode Command Line Tools in the search box in the upper left. Download and install the correct version of the Command Line Tools, for example for OS ”El Capitan” and Xcode 7.2, Kristjan Haule, 2016 –3– KH Computational Physics- 2016 Introduction you need Command Line Tools OS X 10.11 for Xcode 7.2 Apple’s Xcode contains many libraries and compilers for Mac systems.
    [Show full text]
  • SI 413, Unit 3: Advanced Scheme
    SI 413, Unit 3: Advanced Scheme Daniel S. Roche ([email protected]) Fall 2018 1 Pure Functional Programming Readings for this section: PLP, Sections 10.7 and 10.8 Remember there are two important characteristics of a “pure” functional programming language: • Referential Transparency. This fancy term just means that, for any expression in our program, the result of evaluating it will always be the same. In fact, any referentially transparent expression could be replaced with its value (that is, the result of evaluating it) without changing the program whatsoever. Notice that imperative programming is about as far away from this as possible. For example, consider the C++ for loop: for ( int i = 0; i < 10;++i) { /∗ some s t u f f ∗/ } What can we say about the “stuff” in the body of the loop? Well, it had better not be referentially transparent. If it is, then there’s no point in running over it 10 times! • Functions are First Class. Another way of saying this is that functions are data, just like any number or list. Functions are values, in fact! The specific privileges that a function earns by virtue of being first class include: 1) Functions can be given names. This is not a big deal; we can name functions in pretty much every programming language. In Scheme this just means we can do (define (f x) (∗ x 3 ) ) 2) Functions can be arguments to other functions. This is what you started to get into at the end of Lab 2. For starters, there’s the basic predicate procedure?: (procedure? +) ; #t (procedure? 10) ; #f (procedure? procedure?) ; #t 1 And then there are “higher-order functions” like map and apply: (apply max (list 5 3 10 4)) ; 10 (map sqrt (list 16 9 64)) ; '(4 3 8) What makes the functions “higher-order” is that one of their arguments is itself another function.
    [Show full text]
  • Testing Noninterference, Quickly
    Testing Noninterference, Quickly Cat˘ alin˘ Hrit¸cu1 John Hughes2 Benjamin C. Pierce1 Antal Spector-Zabusky1 Dimitrios Vytiniotis3 Arthur Azevedo de Amorim1 Leonidas Lampropoulos1 1University of Pennsylvania 2Chalmers University 3Microsoft Research Abstract To answer this question, we take as a case study the task of Information-flow control mechanisms are difficult to design and extending a simple abstract stack-and-pointer machine to track dy- labor intensive to prove correct. To reduce the time wasted on namic information flow and enforce termination-insensitive nonin- proof attempts doomed to fail due to broken definitions, we ad- terference [23]. Although our machine is simple, this exercise is vocate modern random testing techniques for finding counterexam- both nontrivial and novel. While simpler notions of dynamic taint ples during the design process. We show how to use QuickCheck, tracking are well studied for both high- and low-level languages, a property-based random-testing tool, to guide the design of a sim- it has only recently been shown [1, 24] that dynamic checks are ple information-flow abstract machine. We find that both sophis- capable of soundly enforcing strong security properties. Moreover, ticated strategies for generating well-distributed random programs sound dynamic IFC has been studied only in the context of lambda- and readily falsifiable formulations of noninterference properties calculi [1, 16, 25] and While programs [24]; the unstructured con- are critically important. We propose several approaches and eval- trol flow of a low-level machine poses additional challenges. (Test- uate their effectiveness on a collection of injected bugs of varying ing of static IFC mechanisms is left as future work.) subtlety.
    [Show full text]
  • An Anti-Locally-Nameless Approach to Formalizing Quantifiers Olivier Laurent
    An Anti-Locally-Nameless Approach to Formalizing Quantifiers Olivier Laurent To cite this version: Olivier Laurent. An Anti-Locally-Nameless Approach to Formalizing Quantifiers. Certified Programs and Proofs, Jan 2021, virtual, Denmark. pp.300-312, 10.1145/3437992.3439926. hal-03096253 HAL Id: hal-03096253 https://hal.archives-ouvertes.fr/hal-03096253 Submitted on 4 Jan 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. An Anti-Locally-Nameless Approach to Formalizing Quantifiers Olivier Laurent Univ Lyon, EnsL, UCBL, CNRS, LIP LYON, France [email protected] Abstract all cases have been covered. This works perfectly well for We investigate the possibility of formalizing quantifiers in various propositional systems, but as soon as (first-order) proof theory while avoiding, as far as possible, the use of quantifiers enter the picture, we have to face one ofthe true binding structures, α-equivalence or variable renam- nightmares of formalization: quantifiers are binders... The ings. We propose a solution with two kinds of variables in question of the formalization of binders does not yet have an 1 terms and formulas, as originally done by Gentzen. In this answer which makes perfect consensus .
    [Show full text]
  • Mathematics in the Computer
    Mathematics in the Computer Mario Carneiro Carnegie Mellon University April 26, 2021 1 / 31 Who am I? I PhD student in Logic at CMU I Proof engineering since 2013 I Metamath (maintainer) I Lean 3 (maintainer) I Dabbled in Isabelle, HOL Light, Coq, Mizar I Metamath Zero (author) Github: digama0 I Proved 37 of Freek’s 100 theorems list in Zulip: Mario Carneiro Metamath I Lots of library code in set.mm and mathlib I Say hi at https://leanprover.zulipchat.com 2 / 31 I Found Metamath via a random internet search I they already formalized half of the book! I .! . and there is some stuff on cofinality they don’t have yet, maybe I can help I Got involved, did it as a hobby for a few years I Got a job as an android developer, kept on the hobby I Norm Megill suggested that I submit to a (Mizar) conference, it went well I Met Leo de Moura (Lean author) at a conference, he got me in touch with Jeremy Avigad (my current advisor) I Now I’m a PhD at CMU philosophy! How I got involved in formalization I Undergraduate at Ohio State University I Math, CS, Physics I Reading Takeuti & Zaring, Axiomatic Set Theory 3 / 31 I they already formalized half of the book! I .! . and there is some stuff on cofinality they don’t have yet, maybe I can help I Got involved, did it as a hobby for a few years I Got a job as an android developer, kept on the hobby I Norm Megill suggested that I submit to a (Mizar) conference, it went well I Met Leo de Moura (Lean author) at a conference, he got me in touch with Jeremy Avigad (my current advisor) I Now I’m a PhD at CMU philosophy! How I got involved in formalization I Undergraduate at Ohio State University I Math, CS, Physics I Reading Takeuti & Zaring, Axiomatic Set Theory I Found Metamath via a random internet search 3 / 31 I .
    [Show full text]
  • Failed to Download the Gnu Archive Emacs 'Failed to Download `Marmalade' Archive', but I See the List in Wireshark
    failed to download the gnu archive emacs 'Failed to download `marmalade' archive', but I see the list in Wireshark. I've got 129 packets from marmalade-repo.org , many of which list Marmalade package entries, in my Wireshark log. I'm not behind a proxy and HTTP_PROXY is unset. And ELPA (at 'http://tromey.com/elpa/') works fine. I'm on Max OS X Mavericks, all-up-to-date, with Aquamacs, and using the package.el (byte-compiled) as described here: http://marmalade- repo.org/ (since I am on < Emacs 24). What are the next troubleshooting steps I should take? 1 Answer 1. I've taken Aaron Miller's suggestion and fully migrated to the OS X port of Emacs 24.3 . I do miss being able to use the 'command' key to go to the top of the current file, and the slightly smoother gui of Aquamacs, but it's no doubt a great port. Due to the issue with Marmalade, Emacs 23.4 won't work with some of the packages I now need (unless they were hand-built). Installing ELPA Package System for Emacs 23. This page is a guide on installing ELPA package system package.el for emacs 23. If you are using emacs 24, see: Emacs: Install Package with ELPA/MELPA. (type Alt + x version or in terminal emacs --version .) To install, paste the following in a empty file: then call eval-buffer . That will download the file and place it at. (very neat elisp trick! note to self: url-retrieve-synchronously is bundled with emacs 23.
    [Show full text]
  • Xmonad in Coq: Programming a Window Manager in a Proof Assistant
    xmonad in Coq Programming a window manager in a proof assistant Wouter Swierstra Haskell Symposium 2012 Coq Coq • Coq is ‘just’ a total functional language; • Extraction lets you turn Coq programs into OCaml, Haskell, or Scheme code. • Extraction discards proofs, but may introduce ‘unsafe’ coercions. Demo Extraction to Haskell is not popular. xmonad xmonad • A tiling window manager for X: • arranges windows over the whole screen; • written and configured in Haskell; • has several tens of thousands of users. xmonad: design principles ReaderT StateT IO monad This paper • This paper describes a reimplementation of xmonad’s pure core in Coq; • Extracting Haskell code produces a drop-in replacement for the original module; • Documents my experience. Does it work? Blood Sweat Shell script What happens in the functional core? Data types data Zipper a = Zipper { left :: [a] , focus :: !a , right :: [a] } ... and a lot of functions for zipper manipulation Totality • This project is feasible because most of the functions are structurally recursive. • What about this function? focusLeft (Zipper [] x rs) = let (y : ys) = reverse (x : rs) in Zipper ys y [] Extraction • The basic extracted code is terrible! • uses Peano numbers, extracted Coq booleans, etc. • uses extracted Coq data types for zippers; • generates ‘non-idiomatic’ Haskell. Customizing extraction • There are various hooks to customize the extracted code: • inlining functions; • realizing axioms; • using Haskell data types. Interfacing with Haskell • We would like to use ‘real’ Haskell booleans Extract Inductive bool => "Bool" ["True" "False" ]. • Lots of opportunity to shoot yourself in the foot! Better extracted code • The extracted file uses generated data types and exports ‘too much’ • Solution: • Customize extraction to use hand-coded data types.
    [Show full text]
  • Ledger Mode Emacs Support for Version 3.0 of Ledger
    Ledger Mode Emacs Support For Version 3.0 of Ledger Craig Earls Copyright c 2013, Craig Earls. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are per- mitted provided that the following conditions are met: • Redistributions of source code must retain the above copyright notice, this list of con- ditions and the following disclaimer. • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. • Neither the name of New Artisans LLC nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBU- TORS \AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAM- AGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTER- RUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. i Table of Contents
    [Show full text]
  • A Survey of Engineering of Formally Verified Software
    The version of record is available at: http://dx.doi.org/10.1561/2500000045 QED at Large: A Survey of Engineering of Formally Verified Software Talia Ringer Karl Palmskog University of Washington University of Texas at Austin [email protected] [email protected] Ilya Sergey Milos Gligoric Yale-NUS College University of Texas at Austin and [email protected] National University of Singapore [email protected] Zachary Tatlock University of Washington [email protected] arXiv:2003.06458v1 [cs.LO] 13 Mar 2020 Errata for the present version of this paper may be found online at https://proofengineering.org/qed_errata.html The version of record is available at: http://dx.doi.org/10.1561/2500000045 Contents 1 Introduction 103 1.1 Challenges at Scale . 104 1.2 Scope: Domain and Literature . 105 1.3 Overview . 106 1.4 Reading Guide . 106 2 Proof Engineering by Example 108 3 Why Proof Engineering Matters 111 3.1 Proof Engineering for Program Verification . 112 3.2 Proof Engineering for Other Domains . 117 3.3 Practical Impact . 124 4 Foundations and Trusted Bases 126 4.1 Proof Assistant Pre-History . 126 4.2 Proof Assistant Early History . 129 4.3 Proof Assistant Foundations . 130 4.4 Trusted Computing Bases of Proofs and Programs . 137 5 Between the Engineer and the Kernel: Languages and Automation 141 5.1 Styles of Automation . 142 5.2 Automation in Practice . 156 The version of record is available at: http://dx.doi.org/10.1561/2500000045 6 Proof Organization and Scalability 162 6.1 Property Specification and Encodings .
    [Show full text]