Abstract: A generic tableau prover has been implemented and integrated with Isabelle [Paulson, 1994]. Compared with classical rst-order logic provers, it has numerous extensions that allow it to reason with any supplied set of tableau rules. It has a higherorder syntax in order to support user-de ned binding operators, such as those of set theory. The uni cation algorithm is rst-order instead of higher-order, but it includes modi cations to handle bound variables. The proof, when found, is returned to Isabelle as a list of tactics. Because Isabelle veri es the proof, the prover can cut corners for e ciency's sake without compromising soundness. For example, the prover can use type information to guide the search without storing type information in full. Categories: F.4, I.1

This article explores a synthesis between two distinct traditions in automated reasoning: resolution and interaction. In particular it discusses Isabelle, an interactive theorem prover based upon a form of resolution. It aims to demonstrate the value of proof tools that, compared with traditional resolution systems, seem absurdly limited. Isabelle's classical reasoner searches for proofs using a tableau approach. The reasoner is generic: it accepts rules proved in applied theories, involving defined connectives. The reasoner works in a variety of domains without reducing them to first-order logic. Resolution systems such as Otter [13], setheo [11] and pttp [34] represent automatic theorem proving at its highest point of refinement. They achieve extremely high inference rates and can run continuously for days without running out of storage. They can crack many of the toughest challenge problems that have been circulated. While they exploit many specialized algorithms, data structures and optimizations, they rely crucially on unification. Interactive systems let the user direct each step of the proof. They can implement complicated formalisms, chosen for maximum expressiveness, and typically based on the typed -calculus. hol [7, 8] and pvs [23] are used for verification of hardware and real-time systems, while Coq [4] is used for formalizing mathematics. Large numbers of axioms --- say, the description of a cpu design --- do not overwhelm them, because finding the proof is the user's job. Partial automation is sometimes provided, but a resolution enthusiast would regret the lack of uniform search procedures based on unification. One procedure provided by most interactive provers is rewriting. Rewrite rules have many advantages. Unlike programmed inference rules, they are ...

UNITY is an abstract formalism for proving properties of concurrent systems, which typically are expressed using guarded assignments [Chandy and Misra 1988]. UNITY has been mechanized in higher-order logic using Isabelle, a proof assistant. Safety and progress primitives, their weak forms (for the substitution axiom) and the program composition operator (union) have been formalized. To give a feel for the concrete syntax, the paper presents a few extracts from the Isabelle definitions and proofs. It discusses a small example, two-process mutual exclusion. A mechanical theory of unions of programs supports a degree of compositional reasoning. Original work on extending program states is presented and then illustrated through a simple example involving an array of processes.

This paper presents a fixedpoint approach to inductive definitions. Instead of using a syntactic test such as "strictly positive," the approach lets definitions involve any operators that have been proved monotone. It is conceptually simple, which has allowed the easy implementation of mutual recursion and iterated definitions. It also handles coinductive definitions: simply replace the least fixedpoint by a greatest fixedpoint. The method

This paper reports experiments on mechanizing a theory of UNITY program composition. The key ingredients are mechanized proofs, compositional reasoning, and the UNITY formalism. ---Mechanical proof tools provide rigour and power, but they are highly sensitive to small changes in the definitions. The gap between the "hand proof" and "mechanical proof" communities makes communication difficult. Unstated assumptions in a hand formalism can cause major problems during its mechanization. Notations designed for hand proofs may not be suitable for mechanical tools

The operational semantics of programming and specification languages is often presented via inference rules and these can generally be mapped into logic programming-like clauses. Such logical encodings of operational semantics can be surprisingly declarative if one uses logics that directly account for term-level bindings and for resources, such as are found in linear logic. Traditional theorem proving techniques, such as unification and backtracking search, can then be applied to animate operational semantic specifications. Of course, one wishes to go a step further than animation: using logic to encode computation should facilitate formal reasoning directly with semantic specifications. We outline an approach to reasoning about logic specifications that involves viewing logic specifications as theories in an object-logic and then using a meta-logic to reason about properties of those object-logic theories. We motivate the principal design goals of a particular meta-logic that has been built for that purpose.

This paper reports a case study in the use of proof planning in the context of higher order syntax. Rippling is a heuristic for guiding rewriting steps in induction that has been used successfully in proof planning inductive proofs using first order representations. Ordinal arithmetic provides a natural set of higher order examples on which transfinite induction may be attempted using rippling. Previously Boyer-Moore style automation could not be applied to such domains. We demonstrate that a higher-order extension of the rippling heuristic is sufficient to plan such proofs automatically. Accordingly, ordinal arithmetic has been implemented in Clam, a higher order proof planning system for induction, and standard undergraduate text book problems have been successfully planned. We show the synthesis of a fixpoint for normal ordinal functions which demonstrates how our automation could be extended to produce more interesting results than the textbook examples tried so far.

Proof tools must be well designed if they...

Abstract. Termination proofs are of critical importance for establishing the correct behavior of both transformational and reactive computing systems. A general setting for establishing termination proofs involves the use of the ordinal numbers, an extension of the natural numbers into the transfinite which were introduced by Cantor in the nineteenth century and are at the core of modern set theory. We present the first comprehensive treatment of ordinal arithmetic on compact ordinal notations and give efficient algorithms for various operations, including addition, subtraction, multiplication, and exponentiation. Using the ACL2 theorem proving system, we implemented our ordinal arithmetic algorithms, mechanically verified their correctness, and developed a library of theorems that can be used to significantly automate reasoning involving the ordinals. To enable users of the ACL2 system to fully utilize our work required that we modify ACL2, e.g., we replaced the underlying representation of the ordinals and added a large library of definitions and theorems. Our modifications are available starting with ACL2 version 2.8. 1.

. Interactive proof assistants can support proof strategies, if the right primitives have been included. These include higher-order syntax, logical variables and a choice of search primitives. Such a system allows experimentation with different automatic proof methods, even for constructive logics, new variable-binding operators, etc. The built-in unification and search make proof procedures easy to implement, typically using tableau methods. Against subgoals that arise in practice, even straightforward heuristics turn out to be powerful. 1 Introduction This paper describes the role of strategic principles in proof assistants, taking Isabelle as an example. I use `strategic' in two senses: first, in the sense of proof strategies, and second, in the sense of decisions that have long-term consequences. Building a proof assistant is a major investment, and we cannot foresee at the outset precisely how it will be used. So we must identify those features that seem likely to be of potential...