Prufrock: A Framework for Constructing Polytypic Theorem Provers Justin Ward Information and Telecommunications Technology Center University of Kansas 2335 Irving Hill Road Lawrence, KS 66045-7612 wardj@ittc.ku.edu Garrin Kimmell Information and Telecommunications Technology Center University of Kansas 2335 Irving Hill Road Lawrence, KS 66045-7612 kimmell@ittc.ku.edu Perry Alexander Information and Telecommunications Technology Center University of Kansas 2335 Irving Hill Road Lawrence, KS 66045-7612 alex@ittc.ku.edu ABSTRACT Current formal software engineering methodologies provide a vast array of languages for specifying correctness proper- ties, as well as a wide assortment automated tools that aid in the verification of specified properties. Unfortunately, the implementation of each such tool requires an early commit- ment to a particular methodology and language, in terms of both high-level semantic concerns and the lower-level syn- tactic representations of properties and proofs. In this pa- per, we present Prufrock, a novel approach to automated reasoning systems, which abstracts semantic concerns over entire classes of potential implementation languages. Pru- frock is a modular prover framework written in the Haskell programming language. It consists of a set of largely inde- pendent logic modules, which define the semantics required for proof over entire classes of abstract syntaxes, using poly- typic programming techniques. Any given representation language may be used for specifying and verifying proper- ties in Prufrock, so long as it provides a semantics consistent with the logic modules that required for a proof. The im- plementation details of the reasoning system thus remain independent of the structure specification language, facil- itating large-scale reuse in the construction of automated reasoning tools. At the same time, Prufrock aids in closing the gap between actual source-level implementation and the formal specification and verification of correctness proper- ties. This paper provides an overview of the major design philosophy behind Prufrock, as well as a brief description of the polytypic techniques that make its implementation possible. 1. INTRODUCTION Verification tools, such as theorem provers, perform their tasks by operating directly on an internal abstract syntax. This syntax encodes the theorems, properties, and axioms used in the verification process. Inference and proof are car- ried out by manipulating this syntax in a logically sound fashion. Unfortunately, this approach can be a serious hin- drance to modularity and reuse. Users of a given verification tool must either formulate their specification of theorems and properties in a compatible syntax from the very beginning, or convert their existing specifications to a syntax suitable for the tool. The former approach results in serious constraints on the formal speci- fication language that may be used, while the latter brings about the risk that the translation of a specification may not correctly capture all of its information. Even if a specifica- tion’s soundness is preserved, the user faces the frustrating task of correlating the verification tool’s output, presented in terms of its own abstract syntax, with the original spec- ification. Thus, we may perceive an understandable fear of commitment whenever the subject of formal methods is broached. While verifying the correctness of a given soft- ware system remains the primary concern throughout the formalized development process, it intersects with a myr- iad of troubling pragmatic concerns related to the method- ology. Developers want a formalized logic that accurately captures the semantics of the software system. This initial choice represents a serious commitment that will reverberate throughout the entire development process. Unfortunately, this choice is dependent not only the suitability of a given specification language, but also on the existence of adequate tools for that language. These difficulties are only amplified for the designers of spec- ification languages. A given language’s utility and overall acceptance is severely hampered by the lack of viable tools to assist in its use. This leaves the designer of a specifica- tion language with a choice similar to that its user: either write a new suite of tools compatible with the language, thus bringing new tools to the language, or provide a means to translate the language into a form accepted by existing tools, thus bringing the language to existing tools. Writing tools requires a great deal of work, much of which requires merely reworking existing proof and verification strategies in a form compatible with the new language’s basic struc- ture. The converse approach, which involves translating the language into the accepted structure of existing tools, may result in the loss of many features that made the language