Automating the Diagram Method to Prove Correctness of Program - - PowerPoint PPT Presentation

automating the diagram method to prove correctness of
SMART_READER_LITE
LIVE PREVIEW

Automating the Diagram Method to Prove Correctness of Program - - PowerPoint PPT Presentation

Automating the Diagram Method to Prove Correctness of Program Transformations David Sabel Goethe-University Frankfurt am Main, Germany WPTE 2018, July 8th, Oxford, UK Research supported by the Deutsche Forschungsgemeinschaft (DFG) under


slide-1
SLIDE 1

Automating the Diagram Method to Prove Correctness

  • f Program Transformations

David Sabel†

Goethe-University Frankfurt am Main, Germany

WPTE 2018, July 8th, Oxford, UK

†Research supported by the Deutsche Forschungsgemeinschaft (DFG) under grant SA 2908/3-1.

slide-2
SLIDE 2

Motivation

reasoning on program transformations w.r.t. operational semantics for program calculi with higher-order constructs and recursive bindings, e.g. letrec-expressions: letrec x1 = s1; . . . ; xn = sn in t extended call-by-need lambda calculi with letrec that model core languages of lazy functional programming languages like Haskell

2/22

slide-3
SLIDE 3

Correctness of Program Transformations

A program transformation T is a binary relation on expressions. It is correct iff e T − → e′ = ⇒ (∀contexts C : C[e]↓ ⇐ ⇒ C[e′]↓) ↓ means successful evaluation e↓ := e

sr,∗

− − → e′ and e′ is a successful result where sr − → is the small-step operational semantics (standard reduction) and

sr,∗

− − → is the reflexive-transitive closure of sr − → As a core proof method, we need to show convergence preservation: e T ′ − → e′ = ⇒ (e ↓ = ⇒ e′ ↓) where T ′ is a contextual closure of T

3/22

slide-4
SLIDE 4

Idea of the Diagram Method

Base case: For all successful e e

successful

e′

program transformation

e′′

successful standard reduction steps

General case: For all programs e e e′ e′′

program transformation standard reduction

e′′′

standard reduction steps program transformation steps

Inductive construction e e′ e′′′ e4

succ. by the induction hypothesis

e5

successful

. . . e′′

successful

4/22

slide-5
SLIDE 5

Focused Languages and Previous Results

The diagram technique was, for instance, used for call-by-need lambda calculi with letrec, data constructors, case, and seq [SSSS08, JFP] and non-determinism [SSS08, MSCS] process calculi with call-by-value [NSSSS07, MFPS] or call-by-need evaluation [SSS11, PPDP] and [SSS12, LICS] reasoning on whether program transformations are improvements w.r.t. the run-time [SSS15, PPDP], [SSS17, SCP], [SSSD18,PPDP] and space [SSD18,WPTE]

5/22

slide-6
SLIDE 6

Focused Languages and Previous Results

The diagram technique was, for instance, used for call-by-need lambda calculi with letrec, data constructors, case, and seq [SSSS08, JFP] and non-determinism [SSS08, MSCS] process calculi with call-by-value [NSSSS07, MFPS] or call-by-need evaluation [SSS11, PPDP] and [SSS12, LICS] reasoning on whether program transformations are improvements w.r.t. the run-time [SSS15, PPDP], [SSS17, SCP], [SSSD18,PPDP] and space [SSD18,WPTE] Conclusions from these works The diagram method works well The method requires to compute overlaps (error-prone, tedious,...) Automation of the method would be valuable

5/22

slide-7
SLIDE 7

Automation of the Diagram-Method

calculus description program transformations Input compute

  • verlaps
  • verlaps

join

  • verlaps

Diagram calculator diagrams translate diagrams (I)TRS prove termination (AProVE/CeTA) Automated induction Structure of the LRSX-Tool

6/22

slide-8
SLIDE 8

Representation of the Input

calculus description program transformations Input compute

  • verlaps
  • verlaps

join

  • verlaps

Diagram calculator diagrams translate diagrams (I)TRS prove termination (AProVE/CeTA) Automated induction Structure of the LRSX-Tool

7/22

slide-9
SLIDE 9

Requirements on the Meta-Syntax

Operational semantics of typical call-by-need calculi (excerpt) Reduction contexts: A ::= [·] | (A e) R ::= A | letrec Env in A | letrec {xi=Ai[xi+1]}n−1

i=1 , xn=An, Env, in A[x1]

Standard-reduction rules and some program transformations: (SR,lbeta) R[(λx.e1) e2] → R[letrec x = e2 in e1] . . . (T,cpx) T[letrec x = y, Env in C[x]] → T[letrec x = y, Env in C[y]] (T,gc,1) T[letrec Env, Env′ in e] → T[letrec Env′ in e], if LetV ars(Env) ∩ FV (e, Env′) = ∅ (T,gc,2) T[letrec Env in e] → T[e] if LetVars(Env) ∩ FV (e) = ∅

Meta-syntax must be capable to represent: contexts of different classes environments Envi and environment chains {xi=Ai[xi+1]}n−1

i=1

8/22

slide-10
SLIDE 10

Syntax of the Meta-Language LRSX

Variables x ∈ Var ::= X

(variable meta-variable)

| x

(concrete variable)

Expressions s ∈ Expr ::= S

(expression meta-variable)

| D[s]

(context meta-variable)

| letrec env in s

(letrec-expression)

| var x

(variable)

| (f r1 . . . rar(f))

(function application)

where ri is oi, si, or xi specified by f

  • ∈ HExprn::= x1. . . . xn.s

(higher-order expression)

Environments env ∈ Env ::= ∅

(empty environment)

| E; env

(environment meta-variable)

| Ch[x, s]; env

(chain meta-variable)

| x = s; env

(binding)

Ch[x, s] represents chains x=C1[var x1]; x1=C2[var x2]; . . . ; xn=Cn[s] where Ci are contexts of class cl(Ch)

9/22

slide-11
SLIDE 11

Binding and Scoping Constraints

There are restrictions on scoping and emptiness: . . .

(T,cpx) T[letrec x = y, Env in C[x]] → T[letrec x = y, Env in C[y]] x, y are not captured by C in C[x], C[y] (T,gc,2) T[letrec Env in e] → T[e] if Env = ∅, LetVars(Env) ∩ FV (e) = ∅

We express them by constraint tuples ∆ = (∆1, ∆2, ∆3): non-empty context constraints ∆1: set of context variables

  • ground substitution ρ satisfies D ∈ ∆1 iff ρ(D) = [·]

non-empty environment constraints ∆2: set of environment variables

  • ρ satisfies E ∈ ∆2 iff ρ(E) = ∅

non-capture constraints (NCCs) ∆3: set of pairs (s, d)

  • ρ satisfies (s, d) iff the hole of ρ(d) does not capture variables of ρ(s)

10/22

slide-12
SLIDE 12

Representation of Rules

Standard reductions and transformations are represented as ℓ →∆ r where ℓ, r are LRSX-expressions and ∆ is a constraint-tuple Example:

(T,gc,2) T[letrec Env in e] → T[e] if LetVars(Env) ∩ FV (e) = ∅

is represented as D[letrec E in S] →(∅,{E},{(S,letrec E in [·])}) D[S]

11/22

slide-13
SLIDE 13

Computing Overlaps

calculus description program transformations Input compute

  • verlaps
  • verlaps

join

  • verlaps

Diagram calculator diagrams translate diagrams (I)TRS prove termination (AProVE/CeTA) Automated induction Structure of the LRSX-Tool

12/22

slide-14
SLIDE 14

Computing Overlaps by Unification

σ(ℓB) σ(ℓA) = σ(rB) unifier σ for {ℓA . = ℓB} · σ(rA)

program transformation standard reduction

* *

13/22

slide-15
SLIDE 15

Computing Overlaps by Unification

σ(ℓB) σ(ℓA) = σ(rB) unifier σ for ({ℓA . = ℓB}, ∆A ∪ ∆B) · σ(rA)

program transformation standard reduction

* * Unification also has to respect the constraints ∆A ∪ ∆B

13/22

slide-16
SLIDE 16

Computing Overlaps by Unification

σ(ℓB) σ(ℓA) = σ(rB) unifier σ for ({ℓA . = ℓB}, ∆A ∪ ∆B) · σ(rA)

program transformation standard reduction

* * Unification also has to respect the constraints ∆A ∪ ∆B Occurrence Restrictions: S-variables at most twice, E-, Ch-, D-variables at most once The Letrec Unification Problem is NP-complete [SSS16, PPDP] Algorithm UnifLRS [SSS16, PPDP] is sound and complete

13/22

slide-17
SLIDE 17

Computing Overlaps by Unification

σ(ℓB) σ(ℓA) = (σ(rB), ∆)

  • utput (σ, ∆) for ({ℓA .

= ℓB}, ∆A ∪ ∆B) · (σ(rA), ∆)

program transformation standard reduction

* * Unification also has to respect the constraints ∆A ∪ ∆B Occurrence Restrictions: S-variables at most twice, E-, Ch-, D-variables at most once The Letrec Unification Problem is NP-complete [SSS16, PPDP] Algorithm UnifLRS [SSS16, PPDP] is sound and complete and computes a finite representation of solutions

13/22

slide-18
SLIDE 18

Computing Joins

calculus description program transformations Input compute

  • verlaps
  • verlaps

join

  • verlaps

Diagram calculator diagrams translate diagrams (I)TRS prove termination (AProVE/CeTA) Automated induction Structure of the LRSX-Tool

14/22

slide-19
SLIDE 19

Computing Diagrams

. (t1, ∇) . (t2, ∇)

program transformation standard reduction

* * computing joins ∗ − →: abstract rewriting by rules ℓ →∆ r meta-variables in ℓ, r are instantiable and meta-variables in ti are fixed rewriting: match ℓ against ti and show that the given constraints ∇ imply the needed constraints ∆ Sound and complete matching algorithm MatchLRS [Sab17, UNIF]

15/22

slide-20
SLIDE 20

Example: (gc)-Transformation

(T,gc) := (T,gc,1) ∪ (T,gc,2)

Unification computes 192 overlaps and joining results in 324 diagrams which can be represented by the diagrams ·

T,gc

  • SR,lbeta

·

SR,lbeta

  • ·

T,gc

·

·

T,gc

  • SR,cp

·

SR,cp

  • ·

T,gc

·

·

T,gc

  • SR,lll

·

SR,lll

  • ·

T,gc

·

·

T,gc

  • SR,lll

· ·

T,gc

  • and the answer diagram

Ans

T,gc

Ans

16/22

slide-21
SLIDE 21

Automated Induction

calculus description program transformations Input compute

  • verlaps
  • verlaps

join

  • verlaps

Diagram calculator diagrams translate diagrams (I)TRS prove termination (AProVE/CeTA) Automated induction Structure of the LRSX-Tool

17/22

slide-22
SLIDE 22

Automated Induction: Ideas [RSSS12, IJCAR]

Ignore the concrete expressions, only keep: kind of rule (SR or transformation) and rule-names, and answers as abstract constant ·

T,gc SR,lbeta

·

SR,lbeta

  • · T,gc

·

Ans

T,gc

Ans

18/22

slide-23
SLIDE 23

Automated Induction: Ideas [RSSS12, IJCAR]

Ignore the concrete expressions, only keep: kind of rule (SR or transformation) and rule-names, and answers as abstract constant ·

T,gc SR,lbeta

·

SR,lbeta

  • · T,gc

·

Ans

T,gc

Ans

Diagrams represent string rewrite rules on strings consisting of elements (SR, name), (T, name), and Answer

(T, gc), (SR, lbeta) → (SR, lbeta), (T, gc) (T, gc), Answer → Answer

18/22

slide-24
SLIDE 24

Automated Induction: Ideas [RSSS12, IJCAR]

Ignore the concrete expressions, only keep: kind of rule (SR or transformation) and rule-names, and answers as abstract constant ·

T,gc SR,lbeta

·

SR,lbeta

  • · T,gc

·

Ans

T,gc

Ans

Diagrams represent string rewrite rules on strings consisting of elements (SR, name), (T, name), and Answer

(T, gc), (SR, lbeta) → (SR, lbeta), (T, gc) (T, gc), Answer → Answer

Termination of the string rewrite system implies successful induction We use term rewrite systems and innermost-termination and apply AProVE and certifier CeTA

18/22

slide-25
SLIDE 25

Advanced Techniques

Symbolic α-Renaming Joining overlaps requires α-renaming (λX.S) (letrec E1 in S′) (λX.S) (letrec E1; E2 in S′) letrec X=(letrec E1 in S′) in S letrec X=(letrec E1; E2 in S′) in S T, gc sr, lbeta sr, lbeta X= may capture free occurrences of X in E2! Solution: Extend the meta-language and algorithms with symbolic α-renamings [Sab17,PPDP]

19/22

slide-26
SLIDE 26

Advanced Techniques (continued)

Transitive Closures Transitive closures of reduction / transformation rules, e.g. A[letrec Env in s]

sr,+

− − → letrec Env in A[s] Encoding of diagrams into TRSs uses free variables on right hand sides to “guess” the number of steps Case-distinctions during search for joins Apply case distinctions whether environments E or contexts D are empty/non-empty and treat the cases separately Rule reformulation (not automated) for a copy rule (cp) the diagram set is a nonterminating TRS Solution: cpT: target of copy not below an abstraction cpd: target of copy inside an abstraction The diagram set for (cpT),(cpd) is a terminating TRS.

20/22

slide-27
SLIDE 27

Experiments

LRSX Tool available from http://goethe.link/LRSXTOOL61 computes diagrams and performs the automated induction 5425 # joins 2242 # joins # overlaps 48 secs. computation time → 7273 # joins 3001 # joins # overlaps 116 secs. computation time ← 14729 # joins 4898 # joins # overlaps 149 secs. computation time → 18089 # joins 6437 # joins # overlaps 255 secs. computation time ← 391264 # joins 87041 # joins # overlaps ∼ 19 hours computation time → 429104 # joins 107333 # joins # overlaps ∼ 16 hours computation time ← Calculus Lneed (11 SR rules, 16 transformations, 2 answers) Calculus L+seq

need (17 SR rules, 18 transformations, 2 answers)

Calculus LR (76 SR rules, 43 transformations, 17 answers)

21/22

slide-28
SLIDE 28

Conclusion and Outlook

Conclusion Automation of the diagram method for meta-language LRSX Algorithms for unification, matching, symbolic α-renaming Encoding technique to apply termination provers for TRSs Experiments show: automation works well for call-by-need calculi Further work Further calculi, e.g., process calculi with structural congruence Proving improvements Nominal techniques to ease reasoning on α-renamings:

Nominal unification with letrec [SSKLV16, LOPSTR] Nominal unification with context variables [SSS18, FSCD]

22/22

slide-29
SLIDE 29

Thank you!