Motivated by the fact that humans perform proof search at a high level and subsequently refine their ideas, Bundy introduced the notion of proof planning [Bun88] as a technique for guiding the search for a proof at an abstract level. Proof planning tries to capture and encode common patterns of reasoning – such as induction – in a in so-called methods which are tactics annotated with pre- and postconditions. Originally, the process of proof planning a theorem was divided into two phases: First, a proof is planned at the level of proof methods. If a proof plan – i.e., a sequence of methods that transform the assumptions of the proof to the conjecture – was found, the corresponding tactics are executed, called expansion. In the case that the execution of these tactics fails the proof planner has to try an alternative.
Though there is no general problem to directly perform a search at the level of tactics, it can be advantageous to perform the search at the level of methods: (i) The attached tactic need not be executed. Thus using only the specification can speed up the search. (ii) The specification of the tactic can be incomplete or may contain additional constraints or control knowledge to restrict the search, i.e., to provide some form of guidance of proof search. Hence the search space for a proof plan is usually considerably smaller than the one for a calculus level proof [Bun02, MS99b] while loosing completeness. In particular, methods provide a top-down approach to proof development. (iii) Due to the more abstract search at the level of proof plans and the declarativity of methods, proof planning is regarded to be human oriented. Indeed, many methods try to simulate human problem solving behavior – they can thus be seen as an attempt to make problem solving knowledge explicit. Consequently, proof plans are often better to read. (iv) Proof methods provide a basis for the integration and combination of external algorithmic systems such as computer algebra systems. This is because their results can easily be integrated and checked afterwards.
Nowadays, proof planners also interleave the expansion with the proof planning phase and execute tactics such as simplification directly. However, the general idea of providing techniques to structure and organize the search space and to generate proofs where the reasoning patterns are transparent remains. To make allowance for these developments, one simply denotes the output generated by a proof planner as proof plan.
RSG98], Ωmega’s proof planner Multi [MM05b], and Isaplanner [Dix05], all of which implement proof planning slightly differently, and all of which use slightly varying termi- nology (see [DJP06] for a comparison).
Proof planning has been successfully applied in a number of first and higher-order settings, including mathematical induction [BvHHS91], hardware verification [CBSB96], higher-order program synthesis [DLS00], nonstandard analysis [MFS02], limit problems [Mel98a, MS99b, Mel98b] and problems in the domain of residue-classes [MPS02].
Over the years, further enhancements took place, aiming at more flexible methods that are no longer restricted to its tactical origins, and the improvement of the global search behavior:
Methodicals: Methodicals represent program constructs such as repeat or if-then-else and allow the combination of several methods to more complex methods, similar to tacti- cals for tactics. In particular, they provide a facility to specify what to do next, i.e., after successful application of a (basic) method.
Due to these extensions of methods the differences between a tactic and a method became unclear [Den04a, Den04b].
Proof critics: Proof critics or failure reasoning (see [Ire92, Ire96, MM05a]) attempt to make use of information from failed proof attempts. They are used (1) to patch a failed proof plan, (2) to suggest a lemma or a generalization, or (3) to introduce a case split. Originally, critics were developed to handle failures of the rippling method in Oyster- Clam. They can significantly expand the reasoning power of proof planning systems. More generally, also backtracking can be understood as a critic. The difference between a critic and a method is that a critic can modify (delete and replace) any part of the proof plan, whereas a method performs a local modification of a branch of the proof plan. Knowledge based proof planning: Knowledge based proof planning [MS99b] focuses on the incorporation of mathematical knowledge into the planning process, as advocated inter alia by Bledsoe [BB77]. One major step is the separation of the heuristic knowledge contained in the preconditions of a method and its explicit representation in the form of control rules. Control rules cannot only reason about the current goals and assumptions, but also about the proof planning history and the proof planning context. Thus, the introduction of control rules makes the control flow more flexible and extends the meta- reasoning facilities of proof planning. In some sense they are similar to the control flow which can be expressed by methodicals, even though this correspondence has not been studied theoretically. Another key step is the integration of other tools in the knowledge base to provide justifications for method applications. For example, Ωmega is linked to classical theorem provers, computer algebra systems and constraint solvers to support the proof search. The use of external systems has several advantages: External reasoning systems can make use of special data structures to speed up the search; only the final proof has to be translated back to the proof assistant. Even if an external system does not provide a proof that can be transferred back to the system, their use is beneficial in situations where finding is much harder than checking. This is for example the case for factorization or integration in the context of computer algebra systems.
Proof planning with multiple strategies: Proof planning with multiple strate- gies [MMS08] is based on the notion of a strategy. A strategy is an instance of an algo- rithm that refines or modifies a partial proof plan. Examples for strategies are instances
of planning-, instantiation- and backtracking algorithms. In particular, the possibility to invoke a planning algorithm with a subset of the available methods allows for a further restriction of the search space by tailoring strategies for solving a subproblem. Several strategies can cooperate during the proof process, where this cooperation is guided by strategic meta-reasoning.
Proof plans as declarative proof scripts: One of the main features of proof plans is the abstract representation of a proof. Similarly, the main feature of a declarative proof is that it is human-readable. The connection between proof plans and declarative proof scripts has been recognized and exploited by Dixon [Dix05]: He observed that it is possible to present a proof plan as a declarative proof script and designed Isaplanner to generate declarative proofs. To represent unjustified steps, Dixon introduced a “gap” command, which can be annotated with a technique to close the gap.
Despite its success proof planning still has problems in practice: (i) It is not trivial to discover common patterns of reasoning or abstract heuristics to guide the proof search. As for all knowledge based systems, there is the risk to put too much specific knowledge in the knowledge base (over tuning) such that eventually all examples can be proved, without being general. Though there are some guidelines in [Bun98] what a common pattern of reasoning is or might be, it is in practice more or less infeasible to check whether the used methods obey those principles or to inspect all control rules which were used for the search. (ii) All proof planning systems have not yet retrieved much practical attention. One reason might be that these systems are difficult to use, to setup, and to customize unless you happen to be a developer. Indeed, similar to the case of tactics, proof planning operators are difficult to specify: the user needs to know the underlying programming language of the proof planner and details about the internals of the implementation. Moreover, the success of proof planners is difficult to judge, as the details of the underlying programming language make it difficult to easily perceive the knowledge encoded in the proof planning operators. (iii) Proof planning is not complete, but neither is human proving. (iv) Even though proof planning claims to be human-oriented and natural in the sense that methods encode common patterns of reasoning, it is nearly impossible for a non logician to successfully encode such a pattern, as these methods are heavily influenced by the underlying calculus, as shown in [BMM+01]. Moreover, in addition to
abstract methods there are usually many rules representing calculus steps such as the decomposition of connectives. Consequently many proofs constructed by the technique of proof planning are still not very natural compared with standard proofs that can be found in mathematical textbooks.