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 grant SA 2908/3-1.
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 x 1 = s 1 ; . . . ; x n = s n in t extended call-by-need lambda calculi with letrec that model core languages of lazy functional programming languages like Haskell 2/22
Correctness of Program Transformations A program transformation T is a binary relation on expressions. It is correct iff e T → e ′ = ⇒ C [ e ′ ] ↓ ) − ⇒ ( ∀ contexts C : C [ e ] ↓ ⇐ sr, ∗ → e ′ and e ′ is a successful result ↓ means successful evaluation e ↓ := e − − where sr − → is the small-step operational semantics (standard reduction) sr, ∗ → is the reflexive-transitive closure of sr and − − − → 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
Idea of the Diagram Method Base case: For all successful e Inductive construction program transformation e e ′ e e ′ successful standard reduction steps e ′′′ e ′′ successful . . . General case: For all programs e by the program induction transformation hypothesis e ′ e standard standard reduction reduction steps e 4 e 5 e ′′ e ′′ e ′′′ program succ. successful successful transformation steps 4/22
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
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
Automation of the Diagram-Method compute translate overlaps diagrams calculus description overlaps (I)TRS diagrams program join prove termination transformations (AProVE/CeTA) overlaps Diagram Automated Input calculator induction Structure of the LRSX-Tool 6/22
Representation of the Input compute translate overlaps diagrams calculus description overlaps (I)TRS diagrams program join prove termination transformations (AProVE/CeTA) overlaps Diagram Automated Input calculator induction Structure of the LRSX-Tool 7/22
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 { x i = A i [ x i +1 ] } n − 1 i =1 , x n = A n , Env , in A [ x 1 ] Standard-reduction rules and some program transformations: (SR,lbeta) R [( λx.e 1 ) e 2 ] → R [ letrec x = e 2 in e 1 ] . . . (T,cpx) T [ letrec x = y, Env in C [ x ]] → T [ letrec x = y, Env in C [ y ]] T [ letrec Env , Env ′ in e ] → T [ letrec Env ′ in e ] , (T,gc,1) 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 Env i and environment chains { x i = A i [ x i +1 ] } n − 1 i =1 8/22
Syntax of the Meta-Language LRSX x ∈ Var ::= X Variables (variable meta-variable) | x (concrete variable) s ∈ Expr ::= S Expressions (expression meta-variable) | D [ s ] (context meta-variable) | letrec env in s (letrec-expression) | var x (variable) | ( f r 1 . . . r ar ( f ) ) (function application) where r i is o i , s i , or x i specified by f o ∈ HExpr n ::= x 1 . . . . x n .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 = C 1 [ var x 1 ]; x 1 = C 2 [ var x 2 ]; . . . ; x n = C n [ s ] where C i are contexts of class cl ( Ch ) 9/22
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
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
Computing Overlaps compute translate overlaps diagrams calculus description overlaps (I)TRS diagrams program join prove termination transformations (AProVE/CeTA) overlaps Diagram Automated Input calculator induction Structure of the LRSX-Tool 12/22
Computing Overlaps by Unification program transformation σ ( ℓ A ) = σ ( ℓ B ) σ ( r B ) standard * reduction · σ ( r A ) * unifier σ for { ℓ A . = ℓ B } 13/22
Computing Overlaps by Unification program transformation σ ( ℓ A ) = σ ( ℓ B ) σ ( r B ) standard * reduction · σ ( r A ) * unifier σ for ( { ℓ A . = ℓ B } , ∆ A ∪ ∆ B ) Unification also has to respect the constraints ∆ A ∪ ∆ B 13/22
Computing Overlaps by Unification program transformation σ ( ℓ A ) = σ ( ℓ B ) σ ( r B ) standard * reduction · σ ( r A ) * unifier σ for ( { ℓ A . = ℓ B } , ∆ A ∪ ∆ B ) 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
Computing Overlaps by Unification program transformation σ ( ℓ A ) = σ ( ℓ B ) ( σ ( r B ) , ∆) standard * reduction · ( σ ( r A ) , ∆) * output ( σ, ∆) for ( { ℓ A . = ℓ B } , ∆ A ∪ ∆ B ) 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
Computing Joins compute translate overlaps diagrams calculus description overlaps (I)TRS diagrams program join prove termination transformations (AProVE/CeTA) overlaps Diagram Automated Input calculator induction Structure of the LRSX-Tool 14/22
Computing Diagrams program transformation . ( t 1 , ∇ ) standard reduction * . ( t 2 , ∇ ) * computing joins ∗ − → : abstract rewriting by rules ℓ → ∆ r meta-variables in ℓ, r are instantiable and meta-variables in t i are fixed rewriting: match ℓ against t i and show that the given constraints ∇ imply the needed constraints ∆ Sound and complete matching algorithm MatchLRS [Sab17, UNIF] 15/22
� � � � � � � � 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 T,gc · · · · SR ,lbeta � SR ,lbeta SR ,cp � SR ,cp � · � · · · T,gc T,gc T,gc T,gc · · · · SR ,lll � SR ,lll SR ,lll � � · T,gc · · T,gc and the answer diagram T,gc � Ans Ans 16/22
Automated Induction compute translate overlaps diagrams calculus description overlaps (I)TRS diagrams program join prove termination transformations (AProVE/CeTA) overlaps Diagram Automated Input calculator induction Structure of the LRSX-Tool 17/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 � · · T,gc � Ans SR ,lbeta � SR ,lbeta Ans � · · T,gc 18/22
Recommend
More recommend
