Proof Checking Antonis Stampoulis Zhong Shao Yale University POPL 2012 Proof assistants are becoming popular in our community CompCert Leroy et al seL4 Klein et al Fourcolor theorem ID: 278511
Download Presentation The PPT/PDF document "Static and User-Extensible" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Static and User-ExtensibleProof Checking
Antonis
Stampoulis
Zhong
Shao
Yale University
POPL 2012Slide2
Proof assistants are becoming popular in our community
CompCert
[Leroy et al.]
seL4 [Klein et al.]Four-color theorem [Gonthier et al.]
1 to 1.5 weeks per paper proof page4 pages of formal proof per 1 page of paper proof
… but they’re still hard to use
[
Asperti
and
Coen
‘10]Slide3
communicated to a fixed proof checkermust spell out all details
use domain-specific lemmas
Formal proofs
communicated to a person
rely on
domain-specific intuitionuse “obviously”
Informal proofsSlide4
procedures that produce proofsdomain-specific tactics good in large developments
but difficult to write!
We need tactics to omit details
u
ntypedproofs within tactics can be wrong!Slide5
Proof assistants are hard to use because
1.
c
annot extend proof checker → lots of details
2. no checking for tactics → lots of potential errorsThese are architectural issuesSlide6
Our contribution:
A new architecture for proof assistants
1.
c
annot extend proof checker → lots of details2. no checking for tactics → lots of potential errors1. extensible proof checker → omit lots of details2. extensible checking for tactics → lots of errors avoided
static checking of contained proofs
full programming model
soundness guaranteed
More specifically:
a
new language
design
a
new
implementation
and a new
metatheory
based on
VeriML
[ICFP’10
]
“intuition” stackSlide7
Architecture of proof assistantsSlide8
Architecture of proof assistants:
main notionsSlide9
Architecture of proof assistants:
Checking proof objects
Proof object
Proof checker
Conversion ruleImplicitly check equivalences(proof omitted)
ConversionSlide10
Architecture of proof assistants:
Checking proof objects
Proof object
Proof checker
Coqβι-conversion
ConversionSlide11
Architecture of proof assistants:
Checking proof objects
Proof object
Proof checker
CoqMTβι-conversion +linear arithmetic
ConversionSlide12
Architecture of proof assistants:
Checking proof objects
Proof object
Proof checker
rich static information(de)composablechecking not extensible
ConversionSlide13
Architecture of proof assistants:
Validating proof scripts
Proof script
Proof checker
Proof objectConversion
evaluation
e
xtensible through tactics
rich programming model
no static information
not (de)
composable
hidden proof state
use conversion for more robust scriptsSlide14
Moving to typed proof scripts
Typed proof script
Type checker
Proof script
Proof object
Proof checker
Conversion
evaluation
Proof checker
Conversion
evaluationSlide15
Moving to typed proof scripts +extensible conversion
Typed proof script
Type checker
Proof checker
Conversion
evaluation
Arithmetic tactic
User tactic
Other tactic
Key insight:
conversion is just a hardcoded trusted tactic
but we can trust other tactics too if they have the right type
User-defined ConversionSlide16
Moving to typed proof scripts +extensible conversion
Typed proof script
evaluation
Key insight:
conversion is just a hardcoded trusted tacticbut we can trust other tactics too if they have the right type
Type checker
Proof checker
Conversion
User-defined Conversion
none of them needs to be hardcoded!
Type checker
User-specified Conversion
Proof checker
Other tacticSlide17
Typed proof scripts +extensible conversion
Typed proof script
evaluation
Type checker
User-specified Conversion
Proof checker
rich static information
user chooses conversion
extensible static checking
smaller proof checker
can generate
proof
objects Slide18
Type checking tactics: an example
c
heck propositions for equivalence
return a proof if they are
raise an exception otherwiseMetatheory result 1. Type safetyIf evaluation succeeds,the returned proof object is validMetatheory result 2. Proof erasureIf evaluation succeeds, a valid proof object exists even if it’s not generatedSlide19
Two modes of
evaluation
evaluation
proof
objectproof erasureevaluationmode controlled per functionTyped proof script
User-specified Conversion
Type checker
Proof checkerSlide20
Typed proof script
Type checker
User-specified Conversion
evaluation
Proof checker
Static checking = type checking + staging under proof-erasure
typechecking
stage-one
evaluation
w
ith proof erasure
evaluation of residual
programSlide21
A stack of conversion rules
conversion in Coq
removed from trusted base
makes most uses of rewrite/
autorewrite unnecessaryring_simplify for Natclose to CoqMTno additions to logic metatheoryactually, with reductionsno proof by reflection or translation validationleveraging static proof scriptsSlide22
A stack of conversion rules
potentially non-terminating
reduce proving for “real” versionsSlide23
Static proof scripts in tacticsSlide24
Require Import Arith.Variable
x : Nat.
Theorem
test1 : 0 + x = x.trivial.Qed
.Theorem test2 : x + 0 = x.trivial.Qed.Motivating Coq ExampleSlide25
Require Import
Arith
.
Variable x : Nat.
Theorem test1 : 0 + x = x.trivial.Qed.Theorem test2 : x + 0 = x.trivial.Qed.Motivating Coq ExampleProof completedSlide26
Require Import
Arith
.
Variable x : Nat.
Theorem test1 : 0 + x = x.trivial.Qed.Theorem test2 : x + 0 = x.trivial.Qed.Motivating Coq ExampleAttempt to save an incomplete proofSlide27
Require Import Arith.Variable
x : Nat.
Theorem
test1 : 0 + x = x.trivial.Qed
.Theorem test2 : x + 0 = x.trivial.Qed.Motivating Coq ExampleConversion rule can prove thisbut can’t prove thisSlide28
Let’s add this to our conversion rule!
write a rewriter based on these lemmas
register it with conversion
now it’s
trivial; lemmas used implicitlySlide29Slide30Slide31
not checked statically
recomputed many times
similar to trivial
uses conversion
P and P’ inferredSlide32
checked at definition time
computed once
transformation of runtime arguments to constant argumentsSlide33
How does it work?Slide34
Implementation
http://www.cs.yale.edu/homes/stampoulis/
type
inferencing
and implicit argumentscompiler to OCamlrewriter code generationinductive typesTalk to me for a demo!Slide35
What’s in the paper and TR
Static and dynamic semantics
Metatheory
:Type-safety theoremProof erasure theoremStatic proof script transformation
Implementation details andexamples implementedTyped proof scripts as flexible proof certificatesSlide36
Related workproof-by-reflection
restricted programming model (total functions)
tedious to set up
here: no need for termination proofsautomation through canonical structures / unification hintsrestricted programming model (logic programming)very hard to debugSlide37
Summary
a
new architecture for proof assistants
user-extensible checking of proofs and tacticsminimal trusted corereduce required effort for formal proofs
Thanks!
http://www.cs.yale.edu/homes/stampoulis/Slide38Slide39
Backup slidesSlide40
Type checking proofs and tactics
Type checker
Proof checker
manipulate proofs and propositions in a type-safe manner
dependent pattern matching on logical termslogic and computation are kept separateBeluga [Pientka & Dunfield ‘08]
Delphin [Poswolsky & Schürmann ‘08]VeriML [
Stampoulis
& Shao ‘10]Slide41
Related workLCF family of proof assistants
no information while writing proof scripts/tactics
Coq /
CoqMTconversion rule is fixedchanging it requires re-engineeringNuPRLextensional type theory and sophisticated conversion
here: user decides conversion (level of undecidability)Beluga / Delphinuse as metalogic for LFhere: the logic is fixed; the language is the proof assistant