PROOF%20WEAVING

1
PROOF WEAVING
Anne Mulhern Computer Sciences Department Universi
ty of Wisconsin-Madison Madison, WI
USA mulhern_at_cs.wisc.edu www.cs.wisc.edu/mulhern
2
Modifying Proofs
Ill use tacticals to make my scripts more robust
must add new, dissimilar constructor
I could modify the proof objects
Ill write a special purpose tactic
I will not ever graduate doing this
But they are very big and complex
and structured
must add new constructor
must fix broken scripts
Done!
3
Mutual Antagonism

• Modular and incremental approaches are ubiquitous
  in computer science
• Theorem provers do not readily support certain
  kinds of modular or incremental proof development
• Transparent dependencies invalidate existing
  proofs when underlying structures are changed

4
Proof Weaving

• A technique for combining
• Separate proof objects
• Of the same theorem
• On different underlying structures
• And forming
• A single proof object
• Of the same theorem
• On a combination of the underlying structures

5
Disclaimer

• There is no implementation
• Demo me typing

6
Dependencies

• If L1 and L2 are two identifiers denoting
  definitions, lemmas, functions, or types, a
  dependency between L1 and L2 exists when L1 is a
  free identifier occurring in the ?-term
  associated with L2.

Proof Reuse with Extended Inductive Types,
Boite, 2004
7
Dependencies on term

• Forall lists of terms, either the length of the
  list is zero or the length of the list is greater
  than zero
• TmTrue, which is a term, is a value
• Equality on terms is decidable

8
Dependencies

• An object L has a transparent dependency with an
  inductive type I, if L has a dependency with an
  induction principle of I, or if a case analysis
  on type I is performed in the ?-term representing
  L.
• An object L has an opaque dependency with an
  inductive type I, if its dependency with I is not
  transparent.

Proof Reuse with Extended Inductive Types,
Boite, 2004
9
Transparent Dependencies Bad

• If a constructor C is added to an inductive type
  I, wherever there is a transparent dependency on
  I the object that contains the transparent
  dependency must be updated to accommodate C.
• Match case added
• Additional argument passed to induction principle

10
Quiz Transparent or Opaque?
Forall lists of terms, either the length of the
list is zero or the length of the list is greater
than zero
Opaque!
11
Quiz Transparent or Opaque?
TmTrue, which is a term, is a value
Opaque!
12
Quiz Transparent or Opaque?
Equality on terms is decidable
Transparent!
13
Inductive term Set TmTrue term
TmFalse term . Lemma eq_dec forall (t t
term), t t t ltgt t.
Inductive term Set TmTrue term
TmFalse term . Lemma eq_dec forall (t t
term), t t t ltgt t. decide
equality. Qed.
Inductive term Set TmTrue term
TmFalse term .
induction t. intro t.case t. left.
reflexivity. right. discriminate. intro
t. case t. right. discriminate. left.
reflexivity. Qed.
14
Transparent Dependency on term
15
Transparent Dependency on term
16
Transparent dependency on term
?
?
?
?
?
17
Transparent dependency on term
induction t. intro t.case t. left.
reflexivity. right. discriminate. intro
t. case t. right.discriminate. left.
reflexivity. Qed.
induction t. intro t.case t. left.
reflexivity. right. discriminate. intro
t. case t. right.discriminate. left.
reflexivity. Qed.
induction t. intro t.case t. left.
reflexivity. right. discriminate.
right. discriminate. intro t. case t.
right. discriminate. left. reflexivity. Qed.
18
False Transparent Dependencies

• Some transparent dependencies are false
  transparent dependencies
• A case analysis is performed
• Most constructors are irrelevant
• False transparent dependencies are removable

19
Outline

• False Transparent Dependencies
• True Transparent Dependencies

20
Outline

• False Transparent Dependencies
• True Transparent Dependencies

21
Transparent Dependency
22
Transparent Dependencies
23
False Transparent Dependencies
(_at_eq_ind term TmTrue (fun e term gt
match e with TmTrue gt True TmFalse gt
False TmIf _ _ _ gt False end) I
(TmIf tm1 tm2 tm3) H1)
24
False Transparent Dependencies
(_at_eq_ind term TmTrue (fun e term gt
match e with TmTrue gt True TmFalse gt
False TmIf _ _ _ gt False end) I
(TmIf tm1 tm2 tm3) H1)
?
?
25
False Transparent Dependencies
(fun e term gt match e with TmTrue gt True
(fun e term gt match e with TmTrue gt True
TmIf _ _ _ gt False
(fun e term gt match e with TmTrue gt True
TmFalse gt False TmIf _ _ _ gt False end)
(fun e term gt match e with TmTrue gt True
TmIf _ _ _ gt False _ gt 0 1 end)
?
26
False Transparent Dependencies
27
False Transparent Dependencies

• Easily identified
• Fixable

28
Outline

• False Transparent Dependencies
• True Transparent Dependencies

29
Outline

• False Transparent Dependencies
• True Transparent Dependencies
• Syntactically similar subterms

30
Syntactically Similar Subterms
31
Template Extraction
match H0 in (typeof t t0) return (t
TmIf tm1 tm2 tm3 -gt t0 x -gt exists x0
term, eval (TmIf tm1 tm2 tm3) x0) with
TTrue gt fun (H1 TmTrue TmIf tm1
tm2 tm3) (H2 TyBool x) gt
False_ind (TyBool x -gt exists x0
term, eval (TmIf tm1 tm2 tm3) x0)
(_at_eq_ind term TmTrue (fun e
term gt match e with
TmTrue gt True
TmIf _ _ _ gt False _ gt 0
1 end) I (TmIf tm1 tm2 tm3)
H1) H2
32
Template Extraction
template (H0 typeof t t0) gt H0 gt
fun (H1 t TmIf tm1 tm2 tm3) (H2 t0 x)
gt False_ind (t0 x -gt
exists x0 term, eval (TmIf tm1 tm2 tm3) x0)
(_at_eq_ind term t (fun
e term gt match e with
t gt True
TmIf _ _ _ gt False _ gt 0
1 end) I (TmIf tm1 tm2 tm3)
H1) H2
33
Term Reconstruction
34
Example if
If an if statement is well typed then it can be
further evaluated.
true Bool
false Bool
35
Observation

• False transparent dependencies and true
  transparent dependencies with syntactically
  similar subterms
• Arise frequently
• Are easily identified
• Are tractable

36
To Weave Proof Objects

• Remove false dependencies in each proof object
• For each proof object
• Reconstruct proof subterms corresponding to the
  constructors in the other proof object
• Reject those terms that are not well-typed
• Weave subterms from each proof together

37
How is this technique working?

• Algorithm performed by hand
• Numerous small examples
• References if statements
• Each separate proof has several hundred lines of
  code
• Six subgoals presented to refine tactic
• Must move to implementation

38
Could this technique be useful?

• Yes
• Size of proof is roughly polynomial in number of
  constructors
• Developer effort linear?

39
Related Work

• Proof Reuse with Extended Inductive Types
  Olivier Boite, TPHOLS 2004
• Generating Generic Functions Johan Jeuring,
  Alexey Rodrigues, Gideon Smeding, WGP 2006
• Plagiator - A learning prover Thomas Kolbe and
  Jurgen Brauburger, CADE-14 1997

40
Topics Not Covered

• Mapping generated proof to proof script
• Simplifying proof terms for easier template
  extraction
• Removing or changing (rather than adding)
  constructors
• Changing the proof statement

41
Future Work

• Implementation
• Requires Coq infrastructure
• Typechecker
• Tools for manipulating AST
• Supporting refactorings

42
Conclusion

• Proof Weaving
• Addresses the drawbacks of tactic reuse and
  specialized tactics
• Is a general technique
• Especially suitable for proofs of programming
  language properties
• Preliminary results are encouraging

43
PROOF WEAVING
Anne Mulhern Computer Sciences Department Universi
ty of Wisconsin-Madison Madison, WI
USA mulhern_at_cs.wisc.edu www.cs.wisc.edu/mulhern
44
Could this technique be useful?