GamePad: A Learning Environment for Theorem Proving

1 INTRODUCTION . Theorem proving is a challenging AI task that involves symbolic reasoning ( e.g. , SMT solvers ( De Moura & Bjørner , 2008 ) ) and intuition guided search . Recent work ( Irving et al. , 2016 ; Loos et al. , 2017 ; Kaliszyk et al. , 2017 ) has shown the promise of applying deep learning techniques in this domain , primarily on tasks useful for automated theorem provers ( e.g. , premise selection ) which operate with little to no human supervision . In this work , we aim to move closer to learning on proofs constructed with human supervision . We look at theorem proving in the realm of formal proofs . A formal proof is systematically derived in a formal system , which makes it possible to algorithmically ( i.e. , with a computer ) check these proofs for correctness . Thus , formal proofs provide perfect learning signal—theorem statements and proofs are unambiguous . Human mathematicians usually do not write proofs in this style , and instead , construct and communicate proofs in natural language . Although the form and level of detail involved in each kind of proof differ , the logical content is similar in both contexts . Our work focuses on interactive theorem provers ( ITPs ) , which are software tools that enable human users to construct formal proofs . ITPs have at least two features that make them compelling environments for exploring the application of learning techniques to theorem proving . First and foremost , ITPs provide full-fledged programmable environments . Consequently , any machine learning infrastructure built for an ITP can be reused across any problem domain crafted to study an aspect of learning and theorem proving . Second , the proofs are constructed by humans , and thus , have the constraint that they must be relatively human-understandable . Hence , ITPs provide access to large amounts of supervised data ( i.e. , expert-constructed proofs of theorems that are mathematically interesting ) . For example , ITPs have been used to build and check the proofs of large mathematical theorems such as the Feit-Thompson theorem ( Gonthier et al. , 2013 ) and provide provable guarantees on complex pieces of software such as the CompCert C compiler ( Leroy et al. , 2012 ) . We introduce a system called GamePad1 that exposes parts of the Coq ITP to enable machine learning tasks and explore a few use cases . We focus on the Coq proof assistant for two reasons . First , ∗Propositionally equal contribution †University of California , Berkeley ‡OpenAI 1Theorem proving as a “ game ” and “ proofs-as-data ” . Coq is a mature system with an active developer community that has been used to formalize nontrivial theorems , including Feit-Thompson and CompCert . Second , Coq supports the extraction of verified software . Consequently , one can prove that a program is correct and then run the verified program . The ease of extraction makes Coq a popular choice for program verification . Our contributions are the following . First , we introduce GamePad , which provides a structured Python representation of Coq proofs ( Section 3 ) , including all the proof states encountered in a proof , the steps taken , and expression abstract syntax trees ( ASTs ) . The tool also enables lightweight interaction with Coq so that it can be used to dynamically build proofs ( e.g. , used as an environment for reinforcement learning ) . Tasks that can leverage this structured representation ( Section 4 ) include position evaluation ( i.e. , predict the number of proof steps left ) and tactic prediction ( i.e. , predict the next proof step to take ) . We also discuss how we can use the structured representation to embed proof states into RD ( Section 5 ) . Second , we demonstrate the synthesis of Coq proof scripts that makes use of a tactic prediction model for a hand-crafted algebraic rewriting problem ( Section 6 ) . Third and finally , we apply baseline models for position evaluation and tactic prediction to the FeitThompson formalization using data extracted by GamePad ( Section 7 ) . The code for GamePad , as well as the associated data sets , models and results , are open source on GitHub at https : //github.com/ml4tp/gamepad . 2 BACKGROUND . To provide context for the rest of this paper , we begin by illustrating the formal proof process and how it can be modeled as a game . We then walk through a simple example of a proof in Coq and end by summarizing the constructs that we will encounter in the rest of the paper . Theorem proving process When humans write a pencil-paper proof , we typically maintain a mental and/or written scratchpad that keeps track of ( 1 ) what we need to show and ( 2 ) the facts we currently have at our disposal . As the proof progresses , the items in this scratchpad changes . For instance , we might transform what we need to show ( e.g. , it suffices to show another statement ) and/or discover new facts ( e.g. , we derive an additional fact as a consequence of known facts ) . When we move from the pencil-paper setting to an ITP such as Coq , we will still have such a scratchpad , but use the ITP ’ s term language to express mathematical statements and the rules of the ITP ’ s formal system to construct the proof instead . Formal theorem proving as a game A game serves as useful mental model of the proving process . The state of the game is a proof state , which looks like the scratchpad and is comprised of ( 1 ) a goal ( expressed in the term language ) stating what we need to prove and ( 2 ) a context containing the assumptions ( also expressed in the term language ) . The starting state has as its goal the statement of a theorem and an empty context , while a final state has as its goal a statement that is trivially true ( i.e. , definitionally equal ) given the context . The aim of a prover is to transform the starting state into a collection of final states using only logically valid transitions , which can affect both the context and the goal . It is possible to obtain multiple final states because some transitions may split a goal into multiple subgoals . For a given ( sub ) goal , a successful proof corresponds to a proof tree , where the root is the start state and all the leaves are final states . An example Coq proof Consider showing that adding 0 to any natural number n is n itself . A paper-pencil proof might proceed by induction on n , where we check that the result holds on the base case ( i.e. , n = 0 ) and the inductive case ( i.e. , n = n+ 1 ) . We can carry out a similar process in Coq , using a sequence of commands called tactics in Coq ’ s tactic language Ltac that indicate what proofs steps to take . For instance , we can use the code induction n ; simpl . to start a proof by induction ( on n ) in Coq . The expressions induction and simpl are tactics ( of arity 1 and 0 respectively ) , the semicolon ; sequences two tactics , and the period . signals the end of one proof step . The effect of the entire command ( up to the period ) is to run induction and then simplify all resulting proof states and is shown in Figure 1 via the green arrows , which connect proof states 1 with 2 and 1 with 3 . After we perform the induction , we see that proof state 2 contains the base case and proof state 3 contains the inductive case . The inductive case has an inductive hypothesis in the context . Proofs in Coq are finished when the goal is trivially true given the context ( e.g. , 0 = 0 given an empty context ) . The collection of proof states and tactic invocations forms a proof tree . Formal definitions Coq provides three equi-expressive term languages that encode logical formulas such as forall n : nat , n + 0 = n. They differ in the amount of annotation they support . Coq ’ s user-facing term language Gallina supports type-inference and other forms of notational convenience ( e.g. , syntactic sugar and extensible parsing ) . Coq ’ s mid-level term language removes all forms of notational convenience . Finally , Coq ’ s kernel-level term language instantiates all types and is the level at which proofs are checked . Thus , the mid-level and kernel-level languages are similar , with the exception that the mid-level term language has a notion of an implicit argument . Implicit arguments occur in application constructs—MM1 . . .Mn ( apply functionM to arguments M1 . . .Mn ) at the kernel-level versus MM ι11 . . .M ιn n at the mid-level , where ιi marks implicit versus non-implicit arguments . Implicit arguments take care of the book-keeping aspects of a formal proof such as the types of all terms involved ; a human prover would usually omit them in a paperpencil proof . Hence , learning with mid-level terms without implicit arguments is closer to humanlevel proving , whereas learning with kernel-level terms is closer to machine-level proving . Coq represents a proof state PS as a tuple 〈Γ , M , n〉 of a local context Γ , a goal termM , and a unique proof state identifier n. A context Γ provides a list of identifiers and their types that expresses all the current assumptions . For instance , the proof state with identifier 3 has Γ = n : nat , IHn : n = n + 0 . A tactic invocation creates edges between the appropriate proof states , which forms a proof tree . Proof states are interpreted in the presence of global state . The global state contains the interpretation of constructs such as constants and constructors that have global scope . It also contains the interpretation of constructs that have stateful effects such as existentials . In particular , it is possible to posit the existence of an object in one proof state and then proceed to perform case analysis resulting in multiple proof states that share the same existential . The GamePad tool ( Section 3 ) exposes the constructs described above ( with the exception of Gallina terms ) as Python data structures , which we can use for building models . 3 GAMEPAD TOOL . We briefly describe the GamePad tool with an emphasis on the data that it exposes and any other design decisions that affect the modeling process . Obtaining proof traces We obtain the proof trace by implementing a patch to Coq ( version 8.6.1 ) that instruments the Coq Ltac interpreter to log the intermediate proof states . The patch also supports SSreflect ( Gonthier & Stéphane Le , 2009 ) , a popular Coq plugin for writing proofs about mathematics . Importantly , the patch does not touch the Coq proof checker , and hence , does not affect the critical part of the system that verifies the correctness of proofs . This implementation choice affords us flexibility in deciding what proof steps to consider atomic . As a reminder , the sequenced tactic induction n ; simpl . ( Section 2 ) can be considered as a single proof step ( read up to the delimiting . ) as in the example , but it is comprised of two primitive tactics—induction and simpl . As the granularity of a proof step has consequences for setting up a tactic prediction task ( Section 4 ) , we made the choice to obtain the finer-grained proof states by modifying Coq directly while maintaining the mapping to the human-level proof script . Thus , the tool records proof states at the granularity of primitive tactics ( i.e. , breaks up ; ) as well as at the granularity of the proof script ( i.e. , . ) Representing Coq proofs We expose the proof trace obtained from Coq as Python data structures , including Coq ’ s mid-level and kernel-level term languages , proof states , proof steps , and proof trees so that they can be manipulated with arbitrary Python code . Consequently , we can build models using this structure . For efficiency reasons , we represent Coq terms in a shared form . Representing terms in a shared form is a necessary technique to scale compilers and ITPs to real-world programs and proofs . In our setting , it is also essential to scaling training/inference to real-world data sets ( see Section 7 ) . Light-weight interaction The API provides a thin wrapper around coqtop , the Coq repl , which can be used to interactively construct proof scripts from within Python ( see Section 6 ) . This component mediates all interaction with Coq , including proof state parsing into GamePad ’ s representation of Coq proofs and sending tactic actions .

Summary: This paper mixes automated theorem proving with machine learning models. The final goal, of course, is to be able to train a model that works in conjunction with an automated theorem proving system to efficiently prove theorems, and, ideally, in a way that resembles the way humans prove theorems. This is a distant goal, and the authors instead focus on several tractable tasks that are required for future progress in this direction. They start by integrating the Coq theorem proving environment with ML frameworks, allowing for the creation of models that perform various tasks related to theorem proving. In particular, they focus on two tasks. One is to estimate how many steps are left to complete the proof given a current proof state. The other is to determine what is a good choice of next step. Finally, they also consider issues surrounding representations of the various data structures involved in proofs (i.e., the proof tree, variables, etc.). They test various models on a synthetic nearly trivial logical expression proof, along with a more complicated (and meaningful real world) group theory result.