Architecture and Challenges of Proof Assistants

Static and User-Extensible
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.]
Four-color theorem [Gonthier et al.]
1 to 1.5 weeks per paper proof page
4 pages of formal proof per 1 page
of paper proof
… but they’re still hard to use
[Asperti and Coen ‘10]
communicated to a 
fixed
proof checker
must spell out all details
use domain-specific
lemmas
Formal proofs
communicated to a
person
rely on 
domain-
specific intuition
use “obviously”
Informal proofs
procedures that produce proofs
domain-specific tactics good in large
developments
but difficult to write!
We need tactics to omit details
-
untyped
-
proofs within tactics
can be wrong!
Proof assistants are hard to use because
1. cannot extend proof checker → lots of details
2. no checking for tactics → lots of potential errors
These are architectural issues
Our contribution:
A new architecture for proof assistants
1. cannot extend proof checker → lots of details
2. no checking for tactics → lots of potential errors
 
1. extensible proof checker → omit lots of details
 
2. 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” stack
Architecture of proof assistants
Architecture of proof assistants:
main notions
Architecture of proof assistants:
Checking proof objects
Proof object
Proof
checker
Conversion rule
Implicitly check
equivalences
(proof omitted)
Architecture of proof assistants:
Checking proof objects
Proof object
Proof
checker
Coq
βι
-
conversion
Architecture of proof assistants:
Checking proof objects
Proof object
Proof
checker
CoqMT
βι
-
conversion +
linear arithmetic
Architecture of proof assistants:
Checking proof objects
Proof object
Proof
checker
-
rich static information
-
(de)composable
-
checking not extensible
Architecture of proof assistants:
Validating proof scripts
Proof script
Proof
checker
Proof object
-
extensible through tactics
-
rich programming model
-
no static information
-
not (de)composable
-
hidden proof state
use conversion for more robust
scripts
Moving to typed proof scripts
Typed proof script
Type checker
Proof script
Proof object
Moving to typed proof scripts +
extensible conversion
Typed proof script
Type checker
Proof
checker
Other tactic
Key insight:
conversion is just a
hardcoded trusted tactic
but we can trust other
tactics too if they have
the right type
Moving to typed proof scripts +
extensible conversion
Typed proof script
Key insight:
conversion is just a
hardcoded trusted tactic
but we can trust other
tactics too if they have
the right type
none of them needs to
be hardcoded!
Other tactic
Typed proof scripts +
extensible conversion
-
rich static information
-
user chooses conversion
-
extensible static checking
-
smaller proof checker
-
can generate proof
objects
Type checking tactics: an example
-
check propositions for equivalence
-
return a proof if they are
-
raise an exception otherwise
Metatheory result 1
. 
Type safety
If evaluation succeeds,
the returned proof object is valid
Metatheory result 2
. 
Proof erasure
If evaluation succeeds, a valid proof
object exists even if it’s not generated
Two modes of evaluation
evaluation
proof
object
proof
erasure
evaluation
mode controlled per
function
Typed proof script
Typed proof script
Type checker
Proof
checker
Static checking = type checking +
staging under proof-erasure
 
typechecking
 
stage-one evaluation
with proof erasure
 
evaluation of residual
program
A stack of conversion rules
conversion in Coq
removed from trusted base
makes most uses of
rewrite/autorewrite
unnecessary
ring_simplify for Nat
close to CoqMT
no additions to logic metatheory
actually, with reductions
no proof by reflection or translation validation
leveraging static proof scripts
A stack of conversion rules
potentially non-
terminating
reduce proving
for “real”
versions
Static proof scripts in tactics
Require Import 
Arith.
Variable
 x : Nat.
Theorem
 test1 : 0 + x = x.
trivial.
Qed
.
Theorem
 test2 : x + 0 = x.
trivial.
Qed
.
Motivating Coq Example
Require Import 
Arith.
Variable
 x : Nat.
Theorem
 test1 : 0 + x = x.
trivial.
Qed
.
Theorem
 test2 : x + 0 = x.
trivial.
Qed
.
Motivating Coq Example
Proof
completed
Require Import 
Arith.
Variable
 x : Nat.
Theorem
 test1 : 0 + x = x.
trivial.
Qed
.
Theorem
 test2 : x + 0 = x.
trivial.
Qed
.
Motivating Coq Example
Attempt to save
an incomplete
proof
Require Import 
Arith.
Variable
 x : Nat.
Theorem
 test1 : 0 + x = x.
trivial.
Qed
.
Theorem
 test2 : x + 0 = x.
trivial.
Qed
.
Motivating Coq Example
Conversion rule
can prove this
but can’t prove
this
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 implicitly
not checked statically
recomputed many times
similar to trivial
uses conversion
P and P’ inferred
checked at definition time
computed once
transformation of runtime
arguments to constant
arguments
How does it work?
Implementation
http://www.cs.yale.edu/homes/stampoulis/
type inferencing and implicit arguments
compiler to OCaml
rewriter code generation
inductive types
Talk to me for a demo!
What’s in the paper and TR
Static and dynamic semantics
Metatheory:
Type-safety theorem
Proof erasure theorem
Static proof script transformation
Implementation details and
examples implemented
Typed proof scripts as flexible
proof certificates
Related work
proof-by-reflection
restricted programming model (total functions)
tedious to set up
here: no need for termination proofs
automation through canonical structures /
unification hints
restricted programming model (logic programming)
very hard to debug
Summary
a new architecture for proof assistants
user-extensible checking of proofs and tactics
minimal trusted core
reduce required effort for formal proofs
Thanks!
http://www.cs.yale.edu/homes/stampoulis/
 
 
Backup slides
Type checking proofs and tactics
 
-
manipulate proofs and
propositions in a type-safe manner
-
dependent pattern matching on
logical terms
-
logic and computation are kept
separate
-
Beluga 
[Pientka & Dunfield ‘08]
 
-
Delphin 
[Poswolsky &  Schürmann ‘08]
-
VeriML 
[Stampoulis & Shao ‘10]
Related work
LCF family of proof assistants
no information while writing proof scripts/tactics
Coq / CoqMT
conversion rule is fixed
changing it requires re-engineering
NuPRL
extensional type theory and sophisticated conversion
here: user decides conversion (level of undecidability)
Beluga / Delphin
use as metalogic for LF
here: the logic is fixed; the language is the proof
assistant
Slide Note
Embed
Share

Explore the architecture of proof assistants, discussing the use of tactics, formal proofs, and the difficulty in utilizing these tools. Discover the contribution of a new architecture for proof assistants, addressing extensibility and error checking, with a focus on soundness guarantees. Delve into the main notions of proof objects, derivation in logic, and the checking of proof objects using various tactics and programs to produce proofs. Overall, understand the complexities and advancements in the field of proof assistants.

  • Proof Assistants
  • Architecture
  • Formal Proofs
  • Error Checking
  • Soundness Guarantee

Uploaded on Sep 20, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. Static and User-Extensible Proof Checking Antonis Stampoulis Yale University POPL 2012 Zhong Shao

  2. Proof assistants are becoming popular in our community CompCert [Leroy et al.] seL4 [Klein et al.] Four-color theorem [Gonthier et al.] but they re still hard to use 1 to 1.5 weeks per paper proof page 4 pages of formal proof per 1 page of paper proof [Asperti and Coen 10]

  3. Formal proofs communicated to a fixed proof checker must spell out all details use domain-specific lemmas Informal proofs communicated to a person rely on domain- specific intuition use obviously calculus linear algebra arithmetic

  4. We need tactics to omit details - untyped procedures that produce proofs domain-specific tactics good in large developments but difficult to write! - proofs within tactics can be wrong!

  5. Proof assistants are hard to use because 1. cannot extend proof checker lots of details 2. no checking for tactics lots of potential errors These are architectural issues

  6. arithmetic Our contribution: intuition stack congruence full programming model soundness guaranteed - A new architecture for proof assistants conversion 1. extensible proof checker omit lots of details 1. cannot extend proof checker lots of details 2. no checking for tactics lots of potential errors 2. extensible checking for tactics lots of errors avoided More specifically: - a new language design - a new implementation - and a new metatheory static checking of contained proofs based on VeriML [ICFP 10]

  7. Architecture of proof assistants

  8. Architecture of proof assistants: main notions Proof object Derivation in a logic Proof checker Checks proof objects Tactic Function producing proof objects Combination of tactics; program producing a proof object Proof script

  9. Architecture of proof assistants: Checking proof objects Conversion rule Proof object Implicitly check equivalences (proof omitted) Proof checker Conversion

  10. Architecture of proof assistants: Checking proof objects Proof object Coq -conversion Proof checker Conversion

  11. Architecture of proof assistants: Checking proof objects Proof object CoqMT -conversion + linear arithmetic Proof checker Conversion

  12. Architecture of proof assistants: Checking proof objects - rich static information - (de)composable - checking not extensible Proof object Proof checker Conversion

  13. Architecture of proof assistants: Validating proof scripts Arithmetic tactic Proof script User tactic - extensible through tactics - rich programming model - no static information - not (de)composable - hidden proof state Other tactic evaluation Proof object Proof checker use conversion for more robust scripts Conversion

  14. Moving to typed proof scripts Arithmetic tactic Arithmetic tactic Typed proof script Proof script User tactic User tactic Other tactic Other tactic Type checker evaluation evaluation Proof object Proof checker checker Proof Conversion Conversion

  15. Moving to typed proof scripts + extensible conversion Arithmetic tactic Typed proof script User tactic Key insight: conversion is just a hardcoded trusted tactic Other tactic Type checker Proof checker but we can trust other tactics too if they have the right type Conversion User-defined Conversion evaluation

  16. Moving to typed proof scripts + extensible conversion Typed proof script Key insight: conversion is just a hardcoded trusted tactic Other tactic Type checker Type checker Proof checker Proof checker but we can trust other tactics too if they have the right type Conversion User-defined Conversion User-specified Conversion none of them needs to be hardcoded! evaluation

  17. Typed proof scripts + extensible conversion Typed proof script - rich static information - user chooses conversion - extensible static checking - smaller proof checker - can generate proof objects Type checker Proof checker User-specified Conversion evaluation

  18. Metatheory result 1. Type safety Type checking tactics: an example If evaluation succeeds, the returned proof object is valid Metatheory result 2. Proof erasure If evaluation succeeds, a valid proof object exists even if it s not generated - check propositions for equivalence - return a proof if they are - raise an exception otherwise

  19. Two modes of evaluation Typed proof script Type checker proof object Proof checker evaluation User-specified Conversion mode controlled per function proof erasure evaluation

  20. Static checking = type checking + staging under proof-erasure Typed proof script typechecking Type checker Proof checker stage-one evaluation with proof erasure User-specified Conversion evaluation of residual program evaluation

  21. A stack of conversion rules arithmetic simplification congruence closure ring_simplify for Nat close to CoqMT no additions to logic metatheory actually, with reductions -conversion makes most uses of rewrite/autorewrite unnecessary conversion in Coq no proof by reflection or translation validation leveraging static proof scripts removed from trusted base

  22. A stack of conversion rules arithmetic simplification na ve arithmetic conversion congruence closure potentially non- terminating reduce proving for real versions na ve equality conversion - conversion

  23. Static proof scripts in tactics

  24. Motivating Coq Example Require Import Arith. Variable x : Nat. Theorem test1 : 0 + x = x. trivial. Qed. Theorem test2 : x + 0 = x. trivial. Qed.

  25. Motivating Coq Example Require Import Arith. Variable x : Nat. Theorem test1 : 0 + x = x. trivial. Qed. Proof completed Theorem test2 : x + 0 = x. trivial. Qed.

  26. Motivating Coq Example Require Import Arith. Variable x : Nat. Theorem test1 : 0 + x = x. trivial. Qed. Attempt to save an incomplete proof Theorem test2 : x + 0 = x. trivial. Qed.

  27. Motivating Coq Example Require Import Arith. Variable x : Nat. Conversion rule can prove this Theorem test1 : 0 + x = x. trivial. Qed. but can t prove this Theorem test2 : x + 0 = x. trivial. Qed.

  28. Lets add this to our conversion rule! - - - write a rewriter based on these lemmas register it with conversion now it s trivial; lemmas used implicitly

  29. similar to trivial uses conversion P and P inferred not checked statically recomputed many times

  30. checked at definition time computed once transformation of runtime arguments to constant arguments

  31. How does it work?

  32. Implementation http://www.cs.yale.edu/homes/stampoulis/ type inferencing and implicit arguments compiler to OCaml rewriter code generation inductive types Talk to me for a demo!

  33. Whats in the paper and TR Static and dynamic semantics Metatheory: Type-safety theorem Proof erasure theorem Static proof script transformation Implementation details and examples implemented Typed proof scripts as flexible proof certificates

  34. Related work proof-by-reflection restricted programming model (total functions) tedious to set up here: no need for termination proofs automation through canonical structures / unification hints restricted programming model (logic programming) very hard to debug

  35. Summary a new architecture for proof assistants user-extensible checking of proofs and tactics minimal trusted core reduce required effort for formal proofs Thanks! http://www.cs.yale.edu/homes/stampoulis/

  36. Backup slides

  37. Type checking proofs and tactics -manipulate proofs and propositions in a type-safe manner -dependent pattern matching on logical terms -logic and computation are kept separate -Beluga [Pientka & Dunfield 08] -Delphin [Poswolsky & Sch rmann 08] -VeriML [Stampoulis & Shao 10] Type checker Proof checker

  38. Related work LCF family of proof assistants no information while writing proof scripts/tactics Coq / CoqMT conversion rule is fixed changing it requires re-engineering NuPRL extensional type theory and sophisticated conversion here: user decides conversion (level of undecidability) Beluga / Delphin use as metalogic for LF here: the logic is fixed; the language is the proof assistant

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#