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: The submission describes a system for applying machine learning to interactive theorem proving. The paper focuses on two tasks: tactic prediction (e.g. attempting a proof by induction) and position evaluation (the number of  remaining steps required for a proof). Experiments show that a neural model outperforms an SVM on both tasks, using proof states sampled from a proof of the Feit-Thompson theorem as a dataset. It's great to see work on applying neural networks to symbolic reasoning. The paper is clearly written, and provides helpful background on interactive theorem proving.