DOCSLIB.ORG

HOL Light Tutorial

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
HOL Light Tutorial HOL Light Tutorial John Harrison Intel Corporation, RA2-406 2501 NW 229th Avenue Hillsboro, OR 97124 USA [email protected] January 14, 2017 Abstract The HOL Light theorem prover can be difficult to get started with. While the manual is fairly detailed and comprehensive, the large amount of background information that has to be absorbed before the user can do anything interesting is intimidating. Here we give an alternative ‘quick start’ guide, aimed at teaching basic use of the system quickly by means of a graded set of examples. Some readers may find it easier to absorb; those who do not are referred after all to the standard manual. “Shouldn’t we read the instructions?” “Do I look like a sissy?” Calvin & Hobbes, 19th April 1988 1 Contents 1 Installation 5 1.1 Cygwin . .5 1.2 OCaml . .5 1.3 HOL Light . .5 1.4 Checkpointing . .8 1.5 Other versions of HOL . .9 2 OCaml toplevel basics 10 3 HOL basics 12 3.1 Terms . 12 3.2 Types . 13 3.3 Theorems . 14 3.4 Derived rules . 16 4 Propositional logic 17 4.1 Proving tautologies . 19 4.2 Low-level logical rules . 21 4.3 Logic design and verification . 22 5 Equations and functions 24 5.1 Curried functions . 26 5.2 Pairing . 27 5.3 Equational reasoning . 28 5.4 Definitions . 31 6 Abstractions and quantifiers 31 6.1 Quantifiers . 33 6.2 First-order reasoning . 35 7 Conversions and rewriting 37 7.1 Conversionals . 38 7.2 Depth conversions . 39 7.3 Matching . 40 7.4 Rewriting . 42 8 Tactics and tacticals 44 8.1 The goalstack . 45 8.2 Inductive proofs about summations . 52 9 HOL’s number systems 54 9.1 Arithmetical decision procedures . 56 9.2 Nonlinear reasoning . 58 9.3 Quantifier elimination . 61 2 10 Inductive definitions 62 10.1 The bug puzzle . 64 10.2 Verification of concurrent programs . 68 11 Wellfounded inductionp 71 11.1 Irrationality of 2 ............................ 73 11.2 Wellfoundedness . 75 12 Changing proof style 75 12.1 Towards more readable proofs . 76 12.2 Example . 78 12.3 The right style? . 81 13 Recursive definitions 82 13.1 Binomial coefficients . 85 13.2 The binomial theorem . 87 14 Sets and functions 90 14.1 Choice and the select operator . 92 14.2 Function calculus . 93 14.3 Some cardinal arithmetic . 96 15 Inductive datatypes 100 15.1 Enumerated types . 100 15.2 Recursive types . 101 15.3 The Fano plane . 105 16 Semantics of programming languages 109 16.1 Semantics of the language . 110 16.2 Determinism . 112 16.3 Weakest preconditions . 114 16.4 Axiomatic semantics . 115 17 Shallow embedding 116 17.1 State and expressions . 116 17.2 Commands . 117 17.3 Hoare rules . 121 17.4 Verification conditions . 125 17.5 Refinement . 129 18 Number theory 131 18.1 Congruences . 133 18.2 Fermat’s Little Theorem . 134 18.3 RSA encryption . 140 3 19 Real analysis 143 19.1 Chebyshev polynomials . 143 19.2 A trivial part of Sarkovskii’s theorem . 148 19.3 Derivatives . 151 20 Embedding of logics 152 20.1 Modal logic . 152 20.2 Deep embedding . 152 20.3 Modal schemas . 154 20.4 Shallow embedding . 162 21 HOL as a functional programming language 163 21.1 Normalizing if-then-else expressions . 164 21.2 Proving properties . 167 21.3 A theorem prover . 172 21.4 Execution . 175 22 Vectors 178 22.1 3-dimensional vectors . 182 22.2 Cross products . 183 23 Custom tactics 185 23.1 The Kochen-Specker paradox . 185 23.2 Formalization in HOL . 186 24 Defining new types 191 24.1 Nonzero 3-vectors . 191 24.2 The projective plane again . 193 24.3 Quotient types . 195 25 Custom inference rules 198 25.1 Ordered rewriting using the LPO . 199 25.2 Critical pairs . 201 25.3 Examples of completion . 205 26 Linking external tools 208 26.1 Maxima . 208 26.2 Interfacing HOL and Maxima . 209 26.3 Factoring . 212 26.4 Antiderivatives and integrals . 213 A The evolution of HOL Light 216 A.1 LCF . 216 A.2 HOL . 218 A.3 Development and applications . 219 A.4 hol90, ProofPower and HOL Light . 220 4 1 Installation HOL Light can fairly easily be made to work on most modern computers. Since the first version (Harrison 1996a), the build process has been simplified considerably. In what follows, we will sometimes assume a Unix-like environment such as Linux. If the reader has access to a Linux machine and feels comfortable with it, its use is rec- ommended. However, users of Windows need not despair, because all the Unix tools needed, and many more useful ones besides, are freely available as part of Cygwin. Non-Windows users, or Windows users determined to work “natively”, can skip the next subsection. 1.1 Cygwin Cygwin is a Linux-like environment that can be run within Windows, without interfer- ing with normal Windows usage. Among other things, it provides a traditional shell from which the usual Unix/Linux software tools are available. Cygwin can be freely downloaded from http://www.cygwin.com/. It is a large system, particularly if you select all the package installation options, so the download and installation can take some time. However it usually seems to be straightforward and unproblematic. After installing Cygwin, simply start a ’Bash shell’. On my Windows machine, for example, I follow the menu sequence Start ! All Programs ! Cygwin ! Cygwin bash shell. This application is a ‘shell’ (Unix jargon for something analogous to a Windows command prompt) from which the later commands below can be invoked as if you were within Linux. We will hereinafter say ‘Linux’ when we mean Linux, some other version of Unix, or Cygwin inside Windows. 1.2 OCaml HOL Light is built on top of the functional programming language Objective CAML (‘OCaml’). To be more precise, HOL Light is written in OCaml and the OCaml read- eval-print loop is the usual means of interacting with HOL Light. So installing OCaml is a prerequisite for using HOL Light. Besides, it is a powerful modern programming language with much to recommend it for a wide range of other applications. OCaml can be installed on a wide range of architectures by following the instruc- tions on the Web site http://caml.inria.fr/ocaml/english.en.html. I normally rebuild the system from sources, even under Cygwin (it only requires a few short commands) but precompiled binaries are available for many platforms. 1.3 HOL Light Finally we are ready to install HOL Light itself. You can download the system by following the link from the HOL Light homepage http://www.cl.cam.ac.uk/ ˜jrh13/hol-light/index.html. The downloaded file can easily be unpacked into its constituent parts by doing the following, assuming the downloaded file is called hol_light.tar.gz in the current directory of the shell: 5 tar xvfz hol_light.tar.gz This will create a directory (folder) called hol_light containing the constituent source files. In a pure Windows environment, when you download the hol_light.tar.gz file, or click on it after first saving it, you will automatically be confronted with the Windows WinZip utility, which will display the list of constituent files. By selecting Extract you can save them all to a folder of your choice, say hol_light. Either at the shell prompt (Linux) or the command prompt (in Windows, usually available via the Accessories menu), move into the appropriate directory by: cd hol_light The first step is to create a special file used by HOL Light to handle parsing and printing within OCaml. In Linux you can just do: make In Windows, you need to issue by hand some commands contained in the Makefile. First check the version of OCaml that you have (e.g. by typing ocaml and observing the version number in the startup banner, then exiting it). Copy the appropriately numbered file pa_j_XXX.ml into the bare pa_j.ml. For example, if running Ocaml version 3.08.2, do copy pa_j_3.08.2.ml pa_j.ml If there isn’t a pa_j_XXX.ml that precisely matches your OCaml version number, pick the closest one; it will probably work. However, versions older than 3.04 have not been tried. Next, issue this command: ocamlc -c -pp "camlp4r pa_extend.cmo q_MLast.cmo" -I +camlp4 pa_j.ml There should now be a file called pa_j.cmo in the current directory. (You can check that it’s there by a directory listing, ls in Linux or dir in Windows.) Now start up an interactive OCaml session by: ocaml or under Cygwin and any other systems where the OCaml num library for arbitrary- precision rational cannot be dynamically loaded: ocamlnum You should see something like this (though the precise OCaml version number may well be a little different). /home/johnh/hol_light$ ocaml Objective Caml version 3.08.2 # 6 This is what it feels like to.
Load more

Recommended publications
  • The Common HOL Platform
    The Common HOL Platform Mark Adams Proof Technologies Ltd, UK Radboud University, Nijmegen, The Netherlands The Common HOL project aims to facilitate porting source code and proofs between members of the HOL family of theorem provers. At the heart of the project is the Common HOL Platform, which defines a standard HOL theory and API that aims to be compatible with all HOL systems. So far, HOL Light and hol90 have been adapted for conformance, and HOL Zero was originally developed to conform. In this paper we provide motivation for a platform, give an overview of the Common HOL Platform’s theory and API components, and show how to adapt legacy systems. We also report on the platform’s successful application in the hand-translation of a few thousand lines of source code from HOL Light to HOL Zero. 1 Introduction The HOL family of theorem provers started in the 1980s with HOL88 [5], and has since grown to include many systems, most prominently HOL4 [16], HOL Light [8], ProofPower HOL [3] and Is- abelle/HOL [12]. These four main systems have developed their own advanced proof facilities and extensive theory libraries, and have been successfully employed in major projects in the verification of critical hardware and software [1, 11] and the formalisation of mathematics [7]. It would clearly be of benefit if these systems could “talk” to each other, specifically if theory, proofs and source code could be exchanged in a relatively seamless manner. This would reduce the considerable duplication of effort otherwise required for one system to benefit from the major projects and advanced capabilities developed on another.
    [Show full text]
  • Interactive Theorem Proving (ITP) Course Web Version
    Interactive Theorem Proving (ITP) Course Web Version Thomas Tuerk ([email protected]) Except where otherwise noted, this work is licened under Creative Commons Attribution-ShareAlike 4.0 International License version 3c35cc2 of Mon Nov 11 10:22:43 2019 Contents Part I Preface 3 Part II Introduction 6 Part III HOL 4 History and Architecture 16 Part IV HOL's Logic 24 Part V Basic HOL Usage 38 Part VI Forward Proofs 46 Part VII Backward Proofs 61 Part VIII Basic Tactics 83 Part IX Induction Proofs 110 Part X Basic Definitions 119 Part XI Good Definitions 163 Part XII Deep and Shallow Embeddings 184 Part XIII Rewriting 192 Part XIV Advanced Definition Principles 246 Part XV Maintainable Proofs 267 Part XVI Overview of HOL 4 289 Part XVII Other Interactive Theorem Provers 302 2 / 315 Part I Preface Except where otherwise noted, this work is licened under Creative Commons Attribution-ShareAlike 4.0 International License. Preface these slides originate from a course for advanced master students it was given by the PROSPER group at KTH in Stockholm in 2017 (see https://www.kth.se/social/group/interactive-theorem-) the course focused on how to use HOL 4 students taking the course were expected to I know functional programming, esp. SML I understand predicate logic I have some experience with pen and paper proofs the course consisted of 9 lectures, which each took 90 minutes there were 19 supervised practical sessions, which each took 2 h usually there was 1 lecture and 2 practical sessions each week students were expected to work about 10 h each
    [Show full text]
  • HOL-Testgen Version 1.8 USER GUIDE
    HOL-TestGen Version 1.8 USER GUIDE Achim Brucker, Lukas Brügger, Abderrahmane Feliachi, Chantal Keller, Matthias Krieger, Delphine Longuet, Yakoub Nemouchi, Frédéric Tuong, Burkhart Wolff To cite this version: Achim Brucker, Lukas Brügger, Abderrahmane Feliachi, Chantal Keller, Matthias Krieger, et al.. HOL-TestGen Version 1.8 USER GUIDE. [Technical Report] Univeristé Paris-Saclay; LRI - CNRS, University Paris-Sud. 2016. hal-01765526 HAL Id: hal-01765526 https://hal.inria.fr/hal-01765526 Submitted on 12 Apr 2018 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. R L R I A P P O R HOL-TestGen Version 1.8 USER GUIDE T BRUCKER A D / BRUGGER L / FELIACHI A / KELLER C / KRIEGER M P / LONGUET D / NEMOUCHI Y / TUONG F / WOLFF B D Unité Mixte de Recherche 8623 E CNRS-Université Paris Sud-LRI 04/2016 R Rapport de Recherche N° 1586 E C H E R C CNRS – Université de Paris Sud H Centre d’Orsay LABORATOIRE DE RECHERCHE EN INFORMATIQUE E Bâtiment 650 91405 ORSAY Cedex (France) HOL-TestGen 1.8.0 User Guide http://www.brucker.ch/projects/hol-testgen/ Achim D. Brucker Lukas Brügger Abderrahmane Feliachi Chantal Keller Matthias P.
    [Show full text]
  • Translating Scala Programs to Isabelle/HOL (System
    Translating Scala Programs to Isabelle/HOL System Description Lars Hupel1 and Viktor Kuncak2 1 Technische Universität München 2 École Polytechnique Fédérale de Lausanne (EPFL) Abstract. We present a trustworthy connection between the Leon verification system and the Isabelle proof assistant. Leon is a system for verifying functional Scala programs. It uses a variety of automated theorem provers (ATPs) to check verification conditions (VCs) stemming from the input program. Isabelle, on the other hand, is an interactive theorem prover used to verify mathematical spec- ifications using its own input language Isabelle/Isar. Users specify (inductive) definitions and write proofs about them manually, albeit with the help of semi- automated tactics. The integration of these two systems allows us to exploit Is- abelle’s rich standard library and give greater confidence guarantees in the cor- rectness of analysed programs. Keywords: Isabelle, HOL, Scala, Leon, compiler 1 Introduction This system description presents a new tool that aims to connect two important worlds: the world of interactive proof assistant users who create a body of verified theorems, and the world of professional programmers who increasingly adopt functional programming to develop important applications. The Scala language (www.scala-lang.org) en- joys a prominent role today for its adoption in industry, a trend most recently driven by the Apache Spark data analysis framework (to which, e.g., IBM committed 3500 researchers recently [16]). We hope to introduce some of the many Scala users to formal methods by providing tools they can use directly on Scala code. Leon sys- tem (http://leon.epfl.ch) is a verification and synthesis system for a subset of Scala [2, 10].
    [Show full text]
  • Importing HOL Light Into Coq Chantal Keller, Benjamin Werner
    Importing HOL Light into Coq Chantal Keller, Benjamin Werner To cite this version: Chantal Keller, Benjamin Werner. Importing HOL Light into Coq. ITP - Interactive Theorem Proving, First International Conference - 2010, Jul 2010, Edimbourg, United Kingdom. pp.307-322. inria-00520604 HAL Id: inria-00520604 https://hal.inria.fr/inria-00520604 Submitted on 23 Sep 2010 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. Importing HOL Light into Coq Chantal Keller1,2 and Benjamin Werner2 1 ENS Lyon 2 INRIA Saclay–ˆIle-de-France at Ecole´ polytechnique Laboratoire d’informatique (LIX) 91128 Palaiseau Cedex France [email protected] [email protected] Abstract. We present a new scheme to translate mathematical devel- opments from HOL Light to Coq, where they can be re-used and re- checked. By relying on a carefully chosen embedding of Higher-Order Logic into Type Theory, we try to avoid some pitfalls of inter-operation between proof systems. In particular, our translation keeps the mathe- matical statements intelligible. This translation has been implemented and allows the importation of the HOL Light basic library into Coq. 1 Introduction 1.1 The curse of Babel? Proof-systems are software dedicated to the development of mechanically checked formal mathematics.
    [Show full text]
  • Towards a Mechanized Metatheory of Standard ML ∗
    Towards a Mechanized Metatheory of Standard ML ∗ Daniel K. Lee Karl Crary Robert Harper Carnegie Mellon University {dklee,crary,rwh}@cs.cmu.edu Abstract small case-studies that expose pitfalls. But even using these best We present an internal language with equivalent expressive power practices, errors and inconsistencies arise that are not easily dis- to Standard ML, and discuss its formalization in LF and the covered. Moreover, as languages evolve, so must the metatheory machine-checked verification of its type safety in Twelf. The in- that supports it, introducing further opportunities for error. ternal language is intended to serve as the target of elaboration in A promising approach to reducing error is to use mechanized an elaborative semantics for Standard ML in the style of Harper and verification tools to ease the burden of proving properties of Stone. Therefore, it includes all the programming mechanisms nec- language definitions. Ideally, a language definition would come essary to implement Standard ML, including translucent modules, equipped with a body of metatheory that is mechanically checked abstraction, polymorphism, higher kinds, references, exceptions, against the definition and that can be extended as need and interest recursive types, and recursive functions. Our successful formaliza- demands. With the development of powerful tools such as mechani- tion of the proof involved a careful interplay between the precise cal theorem provers and logical frameworks, it is becoming feasible formulations of the various mechanisms, and required the invention to put this idea into practice. For example, Klein and Nipkow [17] of new representation and proof techniques of general interest. have recently used the Isabelle theorem prover [23] to formalize a large part of the Java programming language and to prove type Categories and Subject Descriptors D.3.1 [Programming Lan- safety for it.
    [Show full text]
  • Formalising Mathematics in Simple Type Theory
    Formalising Mathematics In Simple Type Theory Lawrence C. Paulson Abstract Despite the considerable interest in new dependent type theories, simple type theory [10] (which dates from 1940) is sufficient to formalise serious topics in mathematics. This point is seen by examining formal proofs of a theorem about stereographic projections. A formalisation using the HOL Light proof assistant is contrasted with one using Isabelle/HOL. Harrison’s technique for formalising Eu- clidean spaces [23] is contrasted with an approach using Isabelle/HOL’s axiomatic type classes [27]. However, every formal system can be outgrown, and mathematics should be formalised with a view that it will eventually migrate to a new formalism. 1 Introduction Let’s begin with Dana Scott: No matter how much wishful thinking we do, the theory of types is here to stay. There is no other way to make sense of the foundations of mathematics. Russell (with the help of Ramsey) had the right idea, and Curry and Quine are very lucky that their unmotivated formalistic systems are not inconsistent.1 [48, p. 413] The foundations of mathematics is commonly understood as referring to philo- sophical conceptions such as logicism (mathematics reduced to logic), formalism (mathematics as “a combinatorial game played with the primitive symbols”) [51, p. 62], Platonism (“mathematics describes a non-sensual reality, which exists inde- pendently . of the human mind”) [17, p. 323] and intuitionism (mathematics as “a arXiv:1804.07860v1 [cs.LO] 20 Apr 2018 production of the human mind”) [26, p. 52]. Some of these conceptions, such as logi- cism and formalism, naturally lend themselves to the idea of doing mathematics in a formal deductive system.
    [Show full text]
  • Two Lectures on Constructive Type Theory
    Two Lectures on Constructive Type Theory Robert L. Constable July 20, 2015 Abstract Main Goal: One goal of these two lectures is to explain how important ideas and problems from computer science and mathematics can be expressed well in constructive type theory and how proof assistants for type theory help us solve them. Another goal is to note examples of abstract mathematical ideas currently not expressed well enough in type theory. The two lec- tures will address the following three specific questions related to this goal. Three Questions: One, what are the most important foundational ideas in computer science and mathematics that are expressed well in constructive type theory, and what concepts are more difficult to express? Two, how can proof assistants for type theory have a large impact on research and education, specifically in computer science, mathematics, and beyond? Three, what key ideas from type theory are students missing if they know only one of the modern type theories? The lectures are intended to complement the hands-on Nuprl tutorials by Dr. Mark Bickford that will introduce new topics as well as address these questions. The lectures refer to recent educational material posted on the PRL project web page, www.nuprl.org, especially the on-line article Logical Investigations, July 2014 on the front page of the web cite. Background: Decades of experience using proof assistants for constructive type theories, such as Agda, Coq, and Nuprl, have brought type theory ever deeper into computer science research and education. New type theories implemented by proof assistants are being developed. More- over, mathematicians are showing interest in enriching these theories to make them a more suitable foundation for mathematics.
    [Show full text]
  • Ott: Effective Tool Support for the Working Semanticist
    JFP 20 (1): 71–122, 2010. c Cambridge University Press 2010 71 doi:10.1017/S0956796809990293 Ott: Effective tool support for the working semanticist PETER SEWELL1, FRANCESCO ZAPPA NARDELLI2, SCOTT OWENS1, GILLES PESKINE1, THOMAS RIDGE1, SUSMIT SARKAR1 andROK STRNISAˇ 1 1University of Cambridge, Computer Laboratory, William Gates Building, 15 JJ Thomson Avenue, Cambridge CB3 0FD, United Kingdom and 2INRIA Paris-Rocquencourt, B.P. 105, 78153 Le Chesnay Cedex, France (e-mail: [email protected]) Abstract Semantic definitions of full-scale programming languages are rarely given, despite the many potential benefits. Partly this is because the available metalanguages for expressing semantics – usually either LATEX for informal mathematics or the formal mathematics of a proof assistant – make it much harder than necessary to work with large definitions. We present a metalanguage specifically designed for this problem, and a tool, Ott, that sanity-checks such definitions and compiles them into proof assistant code for Coq, HOL, and Isabelle/HOL, together with LATEX code for production-quality typesetting, and OCaml boilerplate. The main innovations are (1) metalanguage design to make definitions concise, and easy to read and edit; (2) an expressive but intuitive metalanguage for specifying binding structures; and (3) compilation to proof assistant code. This has been tested in substantial case studies, including modular specifications of calculi from the TAPL text, a Lightweight Java with Java JSR 277/294 module system proposals, and a large fragment of OCaml (OCamllight, 310 rules), with mechanised proofs of various soundness results. Our aim with this work is to enable a phase change: making it feasible to work routinely, without heroic effort, with rigorous semantic definitions of realistic languages.
    [Show full text]
  • Formalization of Logic in the Isabelle Proof Assistant
    PhD thesis Formalization of Logic in the Isabelle Proof Assistant Anders Schlichtkrull Technical University of Denmark September 14, 2018 PHD-2018-493 Abstract Isabelle is a proof assistant, i.e. a computer program that helps its user to define concepts in mathematics and computer science as well as to prove properties about them. This process is called formalization. Proof assistants aid their users by ensuring that proofs are constructed correctly and by conducting parts of the proofs automatically. A logical calculus is a set of rules and axioms that can be applied to construct theorems of the calculus. Logical calculi are employed in e.g. tools for formal verification of computer programs. Two important properties of logical calculi are soundness and completeness, since they state, respectively, that all theorems of a given calculus are valid, and that all valid statements are theorems of the calculus. Validity is defined by a semantics, which gives meaning to formulas. This thesis describes formalizations in Isabelle of several logics as well as tools built upon these. Specifically this thesis explains and discusses the following contributions of my PhD project: A formalization of the resolution calculus for first-order logic, Herbrand’s theorem and the • soundness and completeness of the calculus. A formalization of the ordered resolution calculus for first-order logic, an abstract prover • based on it and the prover’s soundness and completeness. A verified automatic theorem prover for first-order logic. The prover is a refinement of the • above formalization of an abstract prover. This explicitly shows that the abstract notion of a prover can describe concrete computer programs.
    [Show full text]
  • The History of Standard ML
    The History of Standard ML DAVID MACQUEEN, University of Chicago, USA ROBERT HARPER, Carnegie Mellon University, USA JOHN REPPY, University of Chicago, USA Shepherd: Kim Bruce, Pomona College, USA The ML family of strict functional languages, which includes F#, OCaml, and Standard ML, evolved from the Meta Language of the LCF theorem proving system developed by Robin Milner and his research group at the University of Edinburgh in the 1970s. This paper focuses on the history of Standard ML, which plays a central rôle in this family of languages, as it was the first to include the complete set of features that we now associate with the name “ML” (i.e., polymorphic type inference, datatypes with pattern matching, modules, exceptions, and mutable state). Standard ML, and the ML family of languages, have had enormous influence on the world of programming language design and theory. ML is the foremost exemplar of a functional programming language with strict evaluation (call-by-value) and static typing. The use of parametric polymorphism in its type system, together with the automatic inference of such types, has influenced a wide variety of modern languages (where polymorphism is often referred to as generics). It has popularized the idea of datatypes with associated case analysis by pattern matching. The module system of Standard ML extends the notion of type-level parameterization to large-scale programming with the notion of parametric modules, or functors. Standard ML also set a precedent by being a language whose design included a formal definition with an associated metatheory of mathematical proofs (such as soundness of the type system).
    [Show full text]
  • Turning Proof Assistants Into Programming Assistants
    Turning proof assistants into programming assistants ST Winter Meeting, 3 Feb 2015 Magnus Myréen Why? Why combine proof- and programming assistants? Why proofs? Testing cannot show absence of bugs. Some care very much about bugs. (Applicable to specialist code only…) What is the specification of Microsoft Word? But what about bugs in compilers, library routines, OS? Why? Why combine proof- and programming assistants? If proof assistants were convenient programming environments, then proofs might become more commonplace. Unit proofs, instead of unit tests? Proving some key properties of algorithm implementations? Not necessarily full functional correctness… Trusting your toolchain “ Every compiler we tested was found to crash and also to silently generate wrong code when presented with valid input. ” PLDI’11 Finding and Understanding Bugs in C Compilers Xuejun Yang Yang Chen Eric Eide John Regehr University of Utah, School of Computing “ [The verified part of]{ jxyang ,CompCertchenyang, eeide, regehr }@cs.utah.edu is the only compiler we have tested for which Csmith Abstract 1 int foocannot (void) { find wrong-code errors.Compilers This should be correct. is Tonot improve thefor quality oflack C compilers, of 2trying:signed char we x = 1; have devoted we created Csmith, a randomized test-case generation tool, and 3 unsigned char y = 255; spent three years using it to find compiler bugs. During this period 4 return x > y; aboutwe reportedsix more CPU-years than 325 previously unknown bugs to compiler 5 } developers. Every compiler we tested was found to crash andthe also task to silently generate wrong code when presented with valid input. Figure 1..”We found a bug in the version of GCC that shipped with In this paper we present our compiler-testing tool and the results Ubuntu Linux 8.04.1 for x86.
    [Show full text]