Verified Programs with Binders Martin Clochard, Claude Marché, Andrei Paskevich To cite this version: Martin Clochard, Claude Marché, Andrei Paskevich. Verified Programs with Binders. Programming Languages meets Program Verification, Jan 2014, San Diego, United States. hal-00913431 HAL Id: hal-00913431 https://hal.inria.fr/hal-00913431 Submitted on 3 Dec 2013 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. Verified Programs with Binders ∗ Martin Clochard1,2,3 Claude Marche´2,3 Andrei Paskevich3,2 1ENS Paris, 2Inria Saclay – Ile-de-France,ˆ 3LRI (CNRS & Universite´ Paris-Sud), France Abstract for programming datatypes with binders in a systematic way, so as Programs that treat datatypes with binders, such as theorem provers to avoid classical traps such as variable capture (see [24, 25] for or higher-order compilers, are regularly used for mission-critical an overview). On the other hand, there are also several approaches purposes, and must be both reliable and performant. Formally prov- proposed for reasoning about datatypes with binders (e.g. de Bruijn ing such programs using as much automation as possible is highly indices, locally nameless, nominal or nested representations), typ- desirable. In this paper, we propose a generic approach to handle ically using highly expressive logical frameworks such as those datatypes with binders both in the program and its specification implemented in interactive proof assistants, as exemplified by the in a way that facilitates automated reasoning about such datatypes POPLmark challenge [3]. However, there has been significantly and also leads to a reasonably efficient code. Our method is im- less work considering simultaneously the issues for developing and plemented in the Why3 environment for program verification. We formally proving programs with binders. validate it on the examples of a lambda-interpreter with several re- Our aim is thus to bridge a gap between two seemingly opposite duction strategies and a simple tableaux-based theorem prover. objectives: reasoning easily about datatypes with binders (hence the representation should be simple) and implementing them with Categories and Subject Descriptors F.3.1 [Theory of Computa- a reasonably efficient structure (hence the representation should be tion]: Logics and Meanings of Programs—Specifying and Verify- clever). Instead of looking for a single representation of binders ing and Reasoning about Programs that would be fit for both tasks, we introduce two different repre- Keywords Formal Verification, Binders, Verified Symbolic Com- sentations: one on the logic side to perform reasoning, one on the putations, Automated Theorem Proving implementation side to perform efficient computations. The imple- mentation representation is interpreted to the logic one, assigning to every program object a logical model, which is used in program 1. Introduction specifications. The idea is that almost all logical reasoning is done This work is about developing programs involving datatypes with using the model, without losing efficiency on the program side. binders, in a safe manner. Such datatypes appear when one wants Our method is implemented using the Why3 environment for to represent symbolic expressions, such as logic formulas, alge- program verification [12] that generates proof obligations dis- braic expressions, or abstract syntax trees of programs. As binders charged by external automated and interactive provers. This en- are the natural way to model quantifiers and anonymous function vironment is presented in Section 2. Why3 allows extraction of expressions, they are widely used to formalize logic and program- programs to OCaml code, thereby allowing efficient execution of ming languages. the proved code. In order to deal with datatypes with binders in a In this context, we propose an approach aiming at both produc- generic way, we designed and implemented a general scheme of ing reasonably efficient programs manipulating binders, and for- definitions of such types, together with a procedure for translat- mally verifying their correctness, using as much automation as pos- ing them into Why3 code defining types, operations, lemmas about sible. Typical examples of such programs include theorem provers, them, and also hints for proving those lemmas. This method is de- higher-order language interpreters and compilers, and computer al- tailed in Section 4. gebra systems. Some of these tools are used to produce mission- Our approach is illustrated on several examples: the terms critical code, requiring a high level of trust. Formally proving such of lambda-calculus, the formulas of first-order logic, the terms programs is thus desirable, and handling datatypes with binders is of system F<: (from the POPLmark challenge). For each ex- a major challenge in this task. ample, all properties and programs that are automatically gener- Dealing with binders is an active research area since a long time. ated are formally proved correct with quite limited human assis- On the one hand, there are several generic approaches and tools tance after generation. We experimented with the generated repre- sentations on two case studies: a verified interpreter for lambda- ∗ Work partly supported by the Bware project of the French national re- calculus using several reduction strategies (Section 5), and certi- search organization (ANR-12-INSE-0010, http://bware.lri.fr/) fied sound tableaux-based theorem prover (Section 6). The source files for our developments are available at http://www.lri.fr/ Permission to make digital or hard copies of all or part of this work for personal or ~clochard/. The obtained results validate the fact that the imple- classroom use is granted without fee provided that copies are not made or distributed mentation of datatypes with binders, as generated by our tool, is for profit or commercial advantage and that copies bear this notice and the full citation competitive with hand-written ones. Notice that in order to handle on the first page. Copyrights for components of this work owned by others than the these examples, our approach has to treat the problem of substitu- author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission tion under binders, making it possible to implement, for example, and/or a fee. Request permissions from [email protected]. an innermost reduction strategy or a skolemization procedure. PLPV ’14, January 21, 2014, San Diego, CA, USA. Copyright is held by the owner/author(s). Publication rights licensed to ACM. ACM 978-1-4503-2567-7/14/01. $15.00. http://dx.doi.org/10.1145/2541568.2541571 2. Preliminaries representing every variable by an identifier, causes a lot of trou- 2.1 The Why3 Environment ble when dealing with operations like substitution, as undesirable captures can arise during a naive substitution. Getting it right typi- Why3 is a platform for deductive program verification, providing a cally involves reasoning modulo α-equivalence by renaming bound rich language for specification and programming, called WhyML. variables into fresh ones, which is inefficient and error-prone. Also, It relies on external provers, both automated and interactive, in reasoning modulo α-equivalence requires to state and prove a great order to discharge the auxiliary lemmas and verification conditions. number of invariance results. WhyML is used as an intermediate language for verification of C, Considering a datatype with binders, five operations stand out Java or Ada programs, and is also intended to be comfortable as a as basic blocks, for which there is a general scheme independent of primary programming language. the actual datatype. The specification component of WhyML [6], used to write • program annotations and background theories, is an extension of Construction, in order to build the values of the datatype. It first-order logic. It features ML-style polymorphic types, algebraic includes the important case of variable binding. datatypes, inductive and co-inductive predicates, recursive defini- • Decomposition, usually via pattern-matching. As the inverse of tions over algebraic types. Constructions like pattern matching, let- construction, the case of variable unbinding must be considered. binding and conditionals can be used directly inside formulas and • Equality test—usually modulo α-equivalence. terms. A type, function, or predicate can be either defined or de- clared abstract and axiomatized. The specification part of the lan- • Substitution, in a way that avoids capture. guage can serve as a common format for theorem proving prob- • Testing whether a variable occurs free in a term, or collecting lems, suitable for multiple provers. The Why3 tool generates proof the set of free variables. obligations from lemmas and goals, then dispatches them to mul- tiple provers, including Alt-Ergo, CVC4, CVC3, Z3, E, SPASS, So, from the logic side, a good representation of such a datatype Vampire, Coq, and PVS. As most of the provers do not support is one where those operations are easy to reason about. On the some of the language features, typically pattern matching, polymor- implementation side, efficiency comes first. phic types, or recursion, Why3 applies a series of encoding trans- Let us consider several possible representations of binding, us- formations to eliminate unsupported constructions before dispatch- ing the pure lambda-calculus and the term λx.(λy.xya)xa as an ing a proof obligation. Other transformations can also be imposed example. by the user in order to simplify the proof search. Named representation The programming part of WhyML [12] is a dialect of ML with a number of restrictions to make automated proving viable.