1. Jared Davis The University of Texas at Austin April 6, 2006
__ __ __ __
/ \ / \ (__) | | ____ ___ __ ____
/ \/ \ __ | | / _ | \ \ __ / / / _ |
/ /\ /\ \ | | | | / / | | \ ' ' / / / | |
/ / \__/ \ \ | | | | \ \_| | \ /\ / \ \_| |
/__/ \__\ |__| |__| \____| \/ \/ \____|
~ ~~ \ ~ ~ ~_~~ ~/~ /~ | ~|~ | ~| ~ /~_ ~|~ ~ ~\ ~\~ ~ ~ ~ |~~ ~
~ ~ \~ \~ / ~\~ / ~/ ~ |~ | ~| ~ ~/~/ | |~ ~~/ ~\/ ~~ ~ / / | |~ ~
~ ~ ~ \ ~\/ ~ \~ ~/ ~~ ~__| |~ ~ ~ \_~ ~ ~ .__~ ~\ ~\ ~_| ~ ~ ~~
~~ ~ ~\ ~ /~ ~ ~ ~ ~ __~ | ~ ~ \~__~| ~/__~ ~\__~ ~~___~| ~ ~
~ ~~ ~ \~_/ ~_~/ ~ ~ ~(__~ ~|~_| ~ ~ ~~ ~ ~ ~~ ~ ~ ~~ ~ ~
in ninety minutes
Jared Davis
The University of Texas at Austin
April 6, 2006

2. Executive Summary
A theorem prover should ideally be small and simple so that it can be trusted
But it also needs to be capable of carrying out interesting proofs
We hope to reconcile these goals by developing
A small “core” proof checker, and
A sequence of verified extensions

3. Other Approaches ACL2: 180,000 (7.9 MB) lines of Lisp
The model: everything is trusted
Trust is based on the competence and care of the authors
In practice, soundness bugs are rare but do sometimes occur
Difficult for non-authors to safely extend the prover

4. Other Approaches (2) The LCF Approach Used by COQ/Isabelle/HOL
The type system is trusted, but tactics do not have to be
Types and higher order concepts seem necessary
Easy to write new tactics (?) but less easy to know that they will not encounter errors
I'm not very well versed in this yet

5. Our Plan
We provide an representation of terms, formulas, and proofs as Lisp objects
We write a function, proofp, to check if a proof is valid
(Using our proof rules, w.r.t. a set of axioms, etc.)
We say  is provable if there exists a valid proof of .

6. Our Plan (2)
We write extensions, e.g., proofp-2, which allow additional types of proof steps
Examples: tautology checking, evaluation, rewriting, etc.
We prove (using proofp) that whenever proofp-2 accepts a proof of , then  is provable (in the sense of proofp)
Hence, we have the same confidence in proofp- 2 as we do in proofp
Despite proofp-2 being more complicated

7. Our Plan (3)
We will iterate this process to obtain a stack of proof checkers
Each more powerful than the last
Wherein only the core checker needs to be trusted
The end-user begins with our most powerful checker
And a clear story of how to extend it

8. Primitive Lisp Definitions Recognizers for Syntactic Entities
The Big Picture
Computing Basis
Choose one or many
X86 GCL
X86 SBCL
X86 CLISP
X86 Allegro
PPC GCL
PPC OpMCL
...
Core Proof Checker
(trusted; ~1,500 lines of Lisp)
Common Extensions
(each verified at the previous level)
Our Proof System
Primitive Lisp Definitions
(e.g., len, memberp, ...)
Recognizers for Syntactic Entities
(terms, formulas, and proof objects)
The Core Proof Checker
(inference checkers, main proof checker)
Command Loop
Term Rewriting
Type Reasoning
Generic Evaluation
Tautology Checking
Equality Substitution
Arithmetic Procedure
. . .
Verification
Project
Custom Extensions
(written by the user, each verified by the previous level)
Tactic-like Scripting
(unverified functions for building proofs at the highest-verified level)
Proofs of Interest
(built using everything above)

9. Implementing Milawa Rigorously define the Milawa logic
Mostly done (still need definition principle, lambda/let terms)
Implement the core proof checker
Mostly done (everything but reflection, lambda/let terms)
Implement some useful extensions
I have tautology checking, substitution of equals for equals, evaluation of ground terms, and unconditional rewriting already
Verify that the extensions are sound
This is really the hard part

10. Verifying Extensions
We need to verify the first extension using only the core proof checker
But its rules of inference are extremely limited
How can we reasonably construct this proof?
Our first extension: tautology checking
I have written the tautology checker and proven (in ACL2) its soundness w.r.t. the core proof checker.
This proof is like a sketch. Now we only need to formalize it as a Milawa-checkable proof.

11. Formalizing the Proof Side 1: Simplify the ACL2 proof
Use fewer features of ACL2, so there is less distance between the sketch and the formal proof.
For example, I have already eliminated all type reasoning, linear arithmetic, forward chaining rules, congruences, and MBE.
Side 2: Develop infrastructure for building formal proofs
I have many “builder” functions to create certain proofs
For example, I can build a proof of a ground term's evaluation, a rewriting pass, etc.

12. After Tautology Checking
Once we finish proving that the tautology checker is sound, we can move on to the next extension
Now we can use tautology checking in our proofs, so this should actually be somewhat easier than before
Or, at least, we will not need to be so concerned about the sizes of our proofs.
After finishing several extensions, we should arrive at a reasonably sophisticated proof checker which we can really trust.

13. The Milawa Logic Terms Constants: rationals, symbols, and pairs
Variables
Functions: (f t1 ... tn)
Formulas
Equalities between terms: t1 = t2
Negations: ~F
Disjunctions: F v G

14. Rules of Inference Expansion Derive B v A from A
Contraction Derive A from A v A
Associativity Derive (A v B) v C from A v (B v C)
Cut Derive B v C from A v B and ~A v C
Instantiation Derive A/ from A
Induction [...]

15. Axioms Propositional ~A v A Reflexivity x = x
Equality x1 ≠ y1 v x2 ≠ y2 v x1 ≠ x2 v y1 = y2
Functional Equality
x1 ≠ y1 v v xn ≠ yn v (f x1 ... xn ) = (f y yn )
Base Evaluation
(f c1 ... cn) = x

16. Implementation Highlights
Appeals and the definition of Proofp
A trivial extension and its soundness proof in ACL2
The tour de builders
The tautology checking extension and its proof in ACL2
Discussion of some of the other extensions
Some tiny, formal proofs in Milawa