Crafting a Proof Assistant Andrea Asperti, Claudio Sacerdoti Coen, Enrico Tassi, and Stefano Zacchiroli Department of Computer Science, University of Bologna Mura Anteo Zamboni, 7 – 40127 Bologna, ITALY {asperti,sacerdot,tassi,zacchiro}@cs.unibo.it Abstract. Proof assistants are complex applications whose develop- ment has never been properly systematized or documented. This work is a contribution in this direction, based on our experience with the devel- opment of Matita: a new interactive theorem prover based—as Coq—on the Calculus of Inductive Constructions (CIC). In particular, we analyze its architecture focusing on the dependencies of its components, how they implement the main functionalities, and their degree of reusability. The work is a first attempt to provide a ground for a more direct com- parison between different systems and to highlight the common func- tionalities, not only in view of reusability but also to encourage a more systematic comparison of different softwares and architectural solutions. 1 Introduction In contrast with automatic theorem provers, whose internal architecture is in many cases well documented (see e.g. the detailed description of Vampire in [16]), it is extremely difficult to find good system descriptions for their interactive counterpart. Traditionally, the only component of these systems that is suitably documented is the kernel, namely the part that is responsible for checking the correctness of proofs. Considering that: 1. most systems (claim to) satisfy the so called “De Bruijn criterion”, that is the principle that the correctness of the whole application should depend on the correctness of a sufficiently small (and thus reliable) kernel and 2. interactive proving looks in principle as a less ambitious task than fully automatic proving (this is eventually the feeling of an external observer) one could easily wonder where the complexity of interactive provers comes from. 1 Both points above—especially the second one—are intentionally provocative. They are meant to emphasize that (1) the kernel is possibly the most crucial, but surely not the most important component of interactive provers and (2) formal checking is just one of the activities of interactive provers, and probably not the most relevant one. Of course, interactivity should be understood as a powerful integration rather than as a poor surrogate of automation: the user is supposed to interact when the system alone fails. Interaction, of course, raises a number of additional problems that are not present (or not so crucial) in automatic proving: 1 e.g.: Coq is about 166.000 lines of code, to be compared with 50.000 lines of Otter