proving program termination via term...

Proving Program Terminationvia Term Rewriting

Carsten Fuhs

Birkbeck, University of London

Advanced Course at the International School on Rewriting 2017

Eindhoven, The Netherlands

July 2017

Proving Program Termination via Term Rewriting

1 Overview

2 Termination Analysis of Term Rewriting with Dependency Pairs

3 Haskell: a Pure Functional Language with Lazy Evaluation

4 Java: an Object-Oriented Imperative language with Side Effects

2/48


1 Overview




3/48

Automated Termination Provers for Term Rewrite Systems

AProVE (Aachen, . . . )CiME3 (Paris)HOT (Cachan)Jambox (Amsterdam)Matchbox (Leipzig)Mu-Term (Valencia)MultumNonMulta (Kassel)NaTT (Innsbruck)THOR (Barcelona)TORPA (Eindhoven)TTT2 (Innsbruck)VMTL (Vienna)Wanda (Copenhagen). . .

Powerful push-button terminationanalysis tools for Term RewriteSystems (TRSs)Development spurred by annualInternational Termination Competition(termCOMP) since 2003termCOMP initially for term rewriting,now also C, Java, Haskell, PrologCan we use tools for TRSs also forprogramming languages?

4/48

Termination Analysis for Programs – Why?

push-button analysisdoes not need separate specification (hard to get right)termination is in most cases a desirable propertynon-termination can be security issue (Denial of Service)in 2011: PHP and Java issues with floating-point number parser

http://www.exploringbinary.com/php-hangs-on-numeric-value-2-2250738585072011e-308/http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/

value of termination analysis recognized by industry→ Microsoft’s Terminator project

5/48

http://www.exploringbinary.com/php-hangs-on-numeric-value-2-2250738585072011e-308/

http://www.exploringbinary.com/php-hangs-on-numeric-value-2-2250738585072011e-308/

http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/

http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/

How can Term Rewriting Contribute?

term rewriting is Turing-completecan represent inductive data structures (trees) in a natural way

Idea 1: port techniques from TRSs to each programming language→ but: lots of repeated work

Idea 2: two-stage approachfront-end for language-specific aspects, extracts TRS such thattermination of TRS implies termination of the programback-end: reuse optimized off-the-shelf termination prover for TRSs

This course: How can we construct such a front-end?look at general principlelook at two concrete programming languages as examples

Haskell (functional, lazy)Java (imperative, object-oriented)

6/48


1 Overview




7/48

Example (Division)

R =

minus(x, 0) → x

minus(s(x), s(y)) → minus(x, y)quot(0, s(y)) → 0

quot(s(x), s(y)) → s(quot(minus(x, y), s(y)))

P =

minus](s(x), s(y)) → minus](x, y)

quot](s(x), s(y)) → minus](x, y)quot](s(x), s(y)) → quot](minus(x, y), s(y))

Term rewriting: Evaluate terms by applying rules from R

minus(s(s(0)), s(0)) →R minus(s(0), 0) →R s(0)

Termination: No infinite evaluation sequences t1 →R t2 →R t3 →R . . .Show termination using Dependency Pairs

8/48

Example (Division)

R =

minus(x, 0) → x



P =





Termination: No infinite evaluation sequences t1 →R t2 →R t3 →R . . .

Show termination using Dependency Pairs

8/48

Example (Division)

R =

minus(x, 0) → x



P =





Termination: No infinite evaluation sequences t1 →R t2 →R t3 →R . . .Show termination using Dependency Pairs

8/48

Example (Division)

R =

minus(x, 0) → x



P =



Dependency Pairs [Arts, Giesl, TCS ’00 ]

For TRS R build dependency pairs P (∼ function calls)Show: No ∞ call sequence with P (eval of P’s args via R)Dependency Pair Framework [Giesl et al, JAR ’06 ] (simplified):

while (P 6= ∅) do

find reduction pair (%,�) with P ∪R ⊆ %delete s→ t with s � t from P (� well founded, not monotonic)

Find (%,�) automatically via SAT and SMT solving

8/48

Example (Division)

R =

minus(x, 0) → x



P =




For TRS R build dependency pairs P (∼ function calls)Show: No ∞ call sequence with P (eval of P’s args via R)

Dependency Pair Framework [Giesl et al, JAR ’06 ] (simplified):

while (P 6= ∅) do



8/48

Example (Division)

R =

minus(x, 0) → x



P =




For TRS R build dependency pairs P (∼ function calls)Show: No ∞ call sequence with P (eval of P’s args via R)Dependency Pair Framework [Giesl et al, JAR ’06 ] (simplified):

while (P 6= ∅) do



8/48

Example (Division)

R =

minus(x, 0) → x



P =




For TRS R build dependency pairs P (∼ function calls)Show: No ∞ call sequence with P (eval of P’s args via R)Dependency Pair Framework [Giesl et al, JAR ’06 ] (simplified):while (P 6= ∅) do



8/48

Example (Division)

R =

minus(x, 0) % x

minus(s(x), s(y)) % minus(x, y)quot(0, s(y)) % 0

quot(s(x), s(y)) % s(quot(minus(x, y), s(y)))

P =

minus](s(x), s(y)) % minus](x, y)

quot](s(x), s(y)) % minus](x, y)quot](s(x), s(y)) % quot](minus(x, y), s(y))



find reduction pair (%,�) with P ∪R ⊆ %

delete s→ t with s � t from P (� well founded, not monotonic)


8/48

Example (Division)

R =

minus(x, 0) % x



P =

minus](s(x), s(y))

(%

)minus](x, y)

quot](s(x), s(y))(%

)minus](x, y)

quot](s(x), s(y))(%

)quot](minus(x, y), s(y))





8/48

Example (Division)

R =

minus(x, 0) % x



P =

minus](s(x), s(y))

(%

)minus](x, y)

quot](s(x), s(y))(%

)minus](x, y)

quot](s(x), s(y))(%





Find (%,�) automatically via SAT and SMT solving8/48

Example (Constraints for Division)

R =

minus(x, 0) % x



P =

minus](s(x), s(y))

(%

)minus](x, y)

quot](s(x), s(y))(%

)minus](x, y)

quot](s(x), s(y))(%


Use polynomial interpretation [ · ] over N with

[quot]](x1, x2) = x1 + x2 . [quot](x1, x2) = x1 + x2[minus]](x1, x2) = x1 + x2 [minus](x1, x2) = x1

[0] = 0 [s](x1) = x1 + 1

y (%,�) induced by [ · ] solves all term constraintsy P = ∅y termination of division algorithm proved �

9/48

Example (Constraints for Division)

R =

minus(x, 0) % x



P =

minus](s(x), s(y)) � minus](x, y)

quot](s(x), s(y)) � minus](x, y)quot](s(x), s(y)) � quot](minus(x, y), s(y))

Use polynomial interpretation [ · ] over N with

[quot]](x1, x2) = x1 + x2 . [quot](x1, x2) = x1 + x2[minus]](x1, x2) = x1 + x2 [minus](x1, x2) = x1

[0] = 0 [s](x1) = x1 + 1

y (%,�) induced by [ · ] solves all term constraintsy P = ∅y termination of division algorithm proved �

9/48

From Program to Term Rewriting, high-level

execute program symbolically from initial states of the program,handle language peculiarities here

use generalization of program states, get over-approximation of allpossible program runs (≈ control-flow graph with extra info)related: Abstract Interpretation [Cousot and Cousot, POPL ’77 ]extract TRS from cycles in the representationif TRS terminates⇒ any concrete program execution can use cycles only finitely often⇒ the program must terminate

f : if ......

else...g : while ...

...

init(...)

f(...)

... g(~s)

g(~t)...10/48


execute program symbolically from initial states of the program,handle language peculiarities hereuse generalization of program states, get over-approximation of allpossible program runs (≈ control-flow graph with extra info)related: Abstract Interpretation [Cousot and Cousot, POPL ’77 ]

extract TRS from cycles in the representationif TRS terminates⇒ any concrete program execution can use cycles only finitely often⇒ the program must terminate

f : if ......


...

init(...)

f(...)

... g(~s)

g(~t)...

g(~t) instance of g(~s)

10/48


execute program symbolically from initial states of the program,handle language peculiarities hereuse generalization of program states, get over-approximation of allpossible program runs (≈ control-flow graph with extra info)related: Abstract Interpretation [Cousot and Cousot, POPL ’77 ]extract TRS from cycles in the representation

if TRS terminates⇒ any concrete program execution can use cycles only finitely often⇒ the program must terminate

f : if ......


...

init(...)

f(...)

... g(~s)

g(~t)...


10/48


execute program symbolically from initial states of the program,handle language peculiarities hereuse generalization of program states, get over-approximation of allpossible program runs (≈ control-flow graph with extra info)related: Abstract Interpretation [Cousot and Cousot, POPL ’77 ]extract TRS from cycles in the representationif TRS terminates⇒ any concrete program execution can use cycles only finitely often⇒ the program must terminate

f : if ......


...

init(...)

f(...)

... g(~s)

g(~t)...


10/48


1 Overview




11/48

Here: Haskell

Haskell 98Widely used functional programming languageGoal: analyze termination, reuse techniques for term rewrite systems

Approach[Giesl, Raffelsieper, Schneider-Kamp, Swiderski, Thiemann, TOPLAS ’11 ]

Translate from Haskell 98 to TRSProve termination of the TRS using standard techniques for TRSs

⇒ Implies termination of the Haskell program!

12/48

From Haskell to TRSs

Challengeshigher-order: functional variables, λ-abstractions, . . .But: Standard framework for TRSs works on first-order termslazy evaluationBut: Standard TRS techniques consider all evaluation strategiespolymorphic typesBut: TRSs are untypedusually not all Haskell functions terminate → ∞ data (streams)But: TRS techniques analyze termination of all terms

13/48

Syntax of Haskell

Data Structuresdata Nat = Z | S Nat

type constructor: Nat

of arity 0

data constructors: Z :: Nat, S :: Nat → Natdata List a = Nil | Cons a (List a)

type constructor: List of arity 1data constructors: Nil :: List a, Cons :: a → (List a) → (List a)

14/48

Syntax of Haskell


type constructor: Nat of arity 0data constructors: Z :: Nat, S :: Nat → Nat

data List a = Nil | Cons a (List a)type constructor: List of arity 1data constructors: Nil :: List a, Cons :: a → (List a) → (List a)

14/48

Syntax of Haskell




Terms (well-typed)Variables: x, y, . . .Function Symbols: constructors (Z, S, Nil, Cons) & defined (from, take)Applications (t1 t2)

S Z represents number 1Cons x Nil ≡ (Cons x) Nil represents [x]

14/48

Syntax of Haskell




TypesType Variables: a, b, . . .Applications of type constructors to types: List Nat, a→ (List a), . . .

S Z has type Nat

Cons x Nil has type List a

14/48

Syntax of Haskell




Function Declarations (example)

fromx = Consx (from (Sx)) take Z xs = NiltakenNil = Niltake (Sn) (Consx xs) = Consx (taken xs)

from :: Nat→ List Nat take :: Nat→ (List a)→ (List a)

from x ≡ [x, x+ 1, x+ 2, . . .] take n [x1, . . . , xn, . . .] ≡ [x1, . . . , xn]

14/48

Syntax of Haskell

Function Declarations (general)

f `1 . . . `n = r

f is defined function symboln is arity of fr is arbitrary term`1 . . . `n are linear patterns (terms from constructors and variables)

Function Declarations (example)


from :: Nat→ List Nat take :: Nat→ (List a)→ (List a)

from x ≡ [x, x+ 1, x+ 2, . . .] take n [x1, . . . , xn, . . .] ≡ [x1, . . . , xn]

15/48

Syntax of Haskell

Approach also works withbuilt-in data structurestype classes

All other Haskell constructs are eliminated by automatictransformations!

lambda abstractions

replace \ t1 . . . tn → t with free variables x1, . . . , xmby f x1 . . . xmwhere f x1 . . . xm t1 . . . tn = t

ConditionsLocal Declarations. . .

16/48

Syntax of Haskell



lambda abstractionsreplace \u m→ takeu (fromm)by fwhere f u m = takeu (fromm)


16/48

Syntax of Haskell



lambda abstractionsreplace \u m→ takeu (fromm)by f uwhere f u m = takeu (fromm)


16/48

Syntax of Haskell



lambda abstractionsreplace \ t1 . . . tn → t with free variables x1, . . . , xmby f x1 . . . xmwhere f x1 . . . xm t1 . . . tn = t


16/48

Semantics of Haskell


Evaluation Relation →H

→H fromZ

17/48




→H fromZ evaluation position

17/48




→H fromZ evaluation position→H Cons Z (from (SZ))

17/48




→H fromZ→H Cons Z (from (SZ)) evaluation position

17/48




→H fromZ→H Cons Z (from (SZ)) evaluation position→H Cons Z (Cons (SZ) (from (S (SZ))))

17/48




→H fromZ→H Cons Z (from (SZ))→H Cons Z (Cons (SZ) (from (S (SZ)))) evaluation position

17/48




→H fromZ→H Cons Z (from (SZ))→H Cons Z (Cons (SZ) (from (S (SZ)))) evaluation position→H . . .

17/48




→H fromm→H Consm (from (Sm))→H Consm (Cons (Sm) (from (S (Sm))))→H . . .

17/48




→H take (SZ) (fromm)

17/48




→H take (SZ) (fromm) evaluation position

17/48




→H take (SZ) (fromm) evaluation position→H take (SZ) (Consm (from (Sm)))

17/48




→H take (SZ) (fromm)→H take (SZ) (Consm (from (Sm))) evaluation position

17/48




→H take (SZ) (fromm)→H take (SZ) (Consm (from (Sm))) evaluation position→H Consm (take Z (from (Sm)))

17/48




→H take (SZ) (fromm)→H take (SZ) (Consm (from (Sm)))→H Consm (take Z (from (Sm))) evaluation position

17/48




→H take (SZ) (fromm)→H take (SZ) (Consm (from (Sm)))→H Consm (take Z (from (Sm))) evaluation position→H ConsmNil

17/48

H-Termination

Analyze H-termination:

If I only plug terminating arguments into my initial term,will the Haskell interpreter always give me an answer?

Formally:H-Termination of ground term t if

t does not start infinite evaluation t→H . . .if t→∗H (f t1 . . . tn), f defined, n < arity(f),then (f t1 . . . tn t

′) is also H-terminating if t′ is H-terminatingif t→∗H (c t1 . . . tn), c constructor,then t1, . . . , tn are also H-terminating.

H-Termination of arbitrary term t iftσ H-terminates for all substitutions σ with H-terminating terms.

x

is H-terminatingfrom is not H-terminating (fromZ has infinite evaluation)take u (from m) is H-terminatingCons u (from m) is not H-terminating

18/48

H-Termination







x is H-terminating

from is not H-terminating (fromZ has infinite evaluation)take u (from m) is H-terminatingCons u (from m) is not H-terminating

18/48

H-Termination







x is H-terminatingfrom

is not H-terminating (fromZ has infinite evaluation)take u (from m) is H-terminatingCons u (from m) is not H-terminating

18/48

H-Termination







x is H-terminatingfrom is not H-terminating (fromZ has infinite evaluation)

take u (from m) is H-terminatingCons u (from m) is not H-terminating

18/48

H-Termination







x is H-terminatingfrom is not H-terminating (fromZ has infinite evaluation)take u (from m)

is H-terminatingCons u (from m) is not H-terminating

18/48

H-Termination







x is H-terminatingfrom is not H-terminating (fromZ has infinite evaluation)take u (from m) is H-terminating

Cons u (from m) is not H-terminating

18/48

H-Termination







x is H-terminatingfrom is not H-terminating (fromZ has infinite evaluation)take u (from m) is H-terminatingCons u (from m)

is not H-terminating

18/48

H-Termination







x is H-terminatingfrom is not H-terminating (fromZ has infinite evaluation)take u (from m) is H-terminatingCons u (from m) is not H-terminating

18/48

From Haskell to Termination Graphsfromx = Consx (from (Sx)) take Z xs = Nil

takenNil = Niltake (Sn) (Consx xs) = Consx (taken xs)

Goal: Prove (H-)termination of initial term take u (from m)

Naive approachUse defining equations directlyfails, since from is not terminatingdisregards Haskell’s evaluation strategy

Our approach [Giesl et al, TOPLAS ’11 ]

evaluate initial term a few steps⇒ termination graph (≈ abstract interpretation)our “abstract domain” for Haskell program states: a single termdo not transform Haskell into TRS directly,but transform termination graph into TRS

19/48

From Haskell to Termination Graphs


takeu (fromm)

begin with node marked with initial term4 expansion rules to add children to leaves (more in paper)expansion rules try to evaluate terms

20/48



takeu (fromm)

Case rule:evaluation has to continue with variable uinstantiate u by all possible constructor terms of correct type

20/48



takeu (fromm)

takeZ (fromm) take (Sn) (fromm)

[u/Z] [u/(Sn)]

Case

Case rule:evaluation has to continue with variable uinstantiate u by all possible constructor terms of correct type

20/48



takeu (fromm)


[u/Z] [u/(Sn)]

Case

Main Property of Termination Graphs:

A node is H-terminating if all its children are H-terminating.

20/48



takeu (fromm)


[u/Z] [u/(Sn)]

Case

Eval rule:

performs one evaluation step with →H

20/48



takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)

take (Sn) (Consm (from (Sm)))

Consm (taken (from (Sm)))

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

Eval rule:

performs one evaluation step with →H

20/48



takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

Case and Eval rule perform narrowingw.r.t. Haskell’s evaluation strategy and types

20/48



takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit rule:

if head of term is a constructor like Cons or a variable,then continue with the parameters

20/48



takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

ParSplit rule:

if head of term is a constructor like Cons or a variable,then continue with the parameters

20/48



takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

one could continue with Case, Eval , ParSplit⇒ infinite treeInstead: Ins rule to obtain finite graphs

20/48



takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins rule:if leaf t is instance of t′, then add instantiation edge from t to t′

one may re-use an existing node for t′, if possible

20/48



takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins


one may re-use an existing node for t′, if possible

20/48



takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins


since instantiation is [u/n, m/(S m)], add child nodes n and (S m)

20/48



takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins


since instantiation is [u/n, m/(S m)], add child nodes n and (S m)

20/48



takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit rule:

if head of term is a constructor like S,then continue with the parameter

20/48



takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

ParSplit rule:

if head of term is a constructor like S,then continue with the parameter

20/48



takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

Termination Graphno expansion rule applicable to leaves anymore

20/48



takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

Termination Graphno expansion rule applicable to leaves anymoreGoal: Prove H-termination of all terms in termination graph

20/48

From Termination Graphs to DP Problems

Prove H-termination of all terms in termination graph

⇒ generate a dependency pair for every DP path

takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

a node is H-terminating if all its children are H-terminating

21/48




takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

if node is not H-terminating, then a child is not H-terminating

21/48




takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

not H-terminating node corresponds toinfinite path in graph

21/48




takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

not H-terminating node corresponds toStrongly Connected Component (SCC)

21/48


Prove H-termination of all terms for each SCC


takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

not H-terminating node corresponds toStrongly Connected Component (SCC)

21/48


Every infinite path traverses an instantiation edge infinitely often


takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

21/48


Every infinite path traverses an instantiation edge infinitely often


takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

DP path:

path in SCC from node with incoming instantiation edgeto node with outgoing instantiation edge

21/48


Every infinite path traverses a DP path infinitely often


takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

DP path:

path in SCC from node with incoming instantiation edgeto node with outgoing instantiation edge

21/48


Every infinite path traverses a DP path infinitely often


takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

Dependency Pairs:

if there is a DP path from s to t marked with µ,then generate the dependency pair s µ→ t

21/48


Every infinite path traverses a DP path infinitely often⇒ generate a dependency pair for every DP path

takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

Dependency Pairs:


21/48


Dependency Pair P: take(S(n), from(m))→ take(n, from(S(m)))Rules R: ∅

takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

Dependency Pairs:


21/48


Dependency Pair P: take(S(n), from(m))→ take(n, from(S(m)))

Rules R: ∅ (rules for terms in instance-edge matcher )

takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval

Eval

ParSplit

Ins

ParSplit

Dependency Pairs:


21/48



takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

Dependency Pairs:


21/48



takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

one DP per SCCno rules in R if no defined symbols to evaluate in rhs of DP

21/48


Dependency Pair P: take(S(n), from(m))→ take(n, from(S(m)))Rules R: ∅ termination easy to prove

takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

one DP per SCCno rules in R if no defined symbols to evaluate in rhs of DP

21/48


fromx=Consx (from (Sx)) take Z xs=NiltakenNil=Niltake (Sn) (Consx xs)=Consx (take (p (Sn)) xs)

takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

22/48


fromx=Consx (from (Sx)) take Z xs=NiltakenNil=Nil

p (Sx)=x take (Sn) (Consx xs)=Consx (take (p (Sn)) xs)

takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)



m taken (from (Sm))

n Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplit

22/48


fromx=Consx (from (Sx)) take Z xs=NiltakenNil=Nil

p (Sx)=x take (Sn) (Consx xs)=Consx (take (p (Sn)) xs)

takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)


Consm (take (p (Sn)) (from (Sm)))

m take (p (Sn)) (from (Sm))

p (Sn)

n

Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplitEval

22/48


Dependency Pair P:take(S(n), from(m))→ take(p(S(n)), from(S(m)))

Rule R: p(S(n)) → n

takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)




p (Sn)

n

Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplitEval

22/48




takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)




p (Sn)

n

Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplitEval

R: rules for terms ininstance-edge matcher

22/48




takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)




p (Sn)

n

Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplitEval

Rule path

path fromterm in instance-edge matcherover Eval - and Case nodesto non-Eval and non-Case node

22/48




takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)




p (Sn)

n

Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplitEval

Rules

if there is a rule path froms to t marked with µ ,then generate the rule s µ → t

22/48



Rule R: p(S(n)) → n termination easy to prove

takeu (fromm)

takeZ (fromm)

Nil

take (Sn) (fromm)




p (Sn)

n

Sm

m

[u/Z] [u/(Sn)]

Case

Eval Eval

Eval

ParSplit

Ins

ParSplitEval

Rules

if there is a rule path froms to t marked with µ ,then generate the rule s µ → t

22/48

Experiments

Implementation in termination prover AProVE(uses improved step termination graph → DP problem)

http://aprove.informatik.rwth-aachen.de/

Experiments on Haskell librariesFiniteMap, List, Monad, Prelude, Queue

300 seconds timeoutAProVE shows H-Termination for 999 out of 1272 functions

23/48

The Tool Chain for Haskell

Termination analysis of Haskell 98 via transformation to TRSs

StartTerm

%%KKKKK

KKK

Haskell-Program

// TerminationGraph

// DP Problems // Termination Toolfor TRSs

Language specifics are handled in transformation front-end⇒ Apply TRS analysis back-end for several programming languages!

Successful evaluation on Haskell 98 standard libraries

Details: [Giesl et al., TOPLAS ’11 ]

http://aprove.informatik.rwth-aachen.de/eval/Haskell

24/48

Conclusion of Part I

Analyze program termination in 2 steps:Program → Term rewrite systemTerm rewrite system → termination proof

Termination analysis for languages other than Haskell:

Logic programming: Prolog[van Raamsdonk, ICLP ’97; Schneider-Kamp et al, TOCL ’09;Giesl et al, PPDP ’12]

Object-oriented programming: Java[Otto et al, RTA ’10 ] → tomorrow

AProVE web interface and Eclipse plug-in download at:


25/48

Exercises I

Consider the following Haskell program.

data Nat = Z | S Natdata List a = Nil | Cons a (List a)

mylength Nil = Zmylength (Cons x xs) = S (mylength xs)

mysum Nil = Zmysum (Cons x xs) = plus x (mysum xs)

plus Z y = yplus (S x) y = S (plus x y)

26/48

Exercises II

Question 1

Consider the start term mylength x.

(a) Is this start term H-terminating?(b) Construct a termination graph for this start term.(c) Extract a DP problem from the termination graph from part (b).(d) Prove that this DP problem is “terminating”, i.e., that no infinite call

sequences are possible.(e) Check your solutions with the web interface (or a local installation)

of the termination prover AProVE:http://aprove.informatik.rwth-aachen.de/(note that AProVE preprocesses the termination graph before the stepto DP problems so that the output will look slightly differently).

27/48


Exercises III

Question 2 (slightly harder/more interesting)

Consider the start term mysum x. Proceed with it as in Question 1.Hint: One can draw instantiation edges also to nodes that are not yetpresent in the termination graph.

Question 3

What strengths and limitations do you expect this approach to terminationproving of Haskell programs to have?

28/48


1 Overview




29/48

Recap: from Haskell to Term Rewriting for Termination

Recipe for proving program termination by reusing TRS termination proversDecide on suitable symbolic representation of abstract program states(abstract domain)→ what data objects can we represent as terms?Execute program symbolically from its initial statesUse generalization of program states to get closed finiterepresentation (termination graph, abstract interpretation)Extract rewrite rules that “over-approximate” program runs instrongly-connected components of graphProve termination of these rewrite rules⇒ implies termination of program from initial states

Yesterday: Haskell, today: Java

30/48

Beyond Classic TRSs for Programs

Rewrite rules for Haskell programs in standard term rewriting→ no predefined rules for addition, multiplication, etc.

Drawbacks:throws away domain knowledge about built-in data types like integersneed to analyze recursive rules for plus, times, . . . over and overdoes not benefit from dedicated constraint solvers(SMT: SAT Modulo Theories) for arithmetic operations

Solution: use constrained term rewriting

31/48

Constrained Term Rewriting, what’s that?

Term rewriting “with batteries included”

first-orderno fixed evaluation strategyno fixed order of rules to applytypedwith pre-defined data structures (integers, arrays, bitvectors, ...),usually from SMT-LIB theoriesrewrite rules with SMT constraints

⇒ Term rewriting + SMT solving for automated reasoning

General forms available, e.g., Logically Constrained TRSs[Kop, Nishida, FroCoS ’13 ]

For program termination: use term rewriting with integers[Falke, Kapur, CADE ’09; Fuhs et al, RTA ’09; Giesl et al, JAR ’17]

32/48

Constrained Rewriting by Example

Consider a variation of the take-from program . . .

Example (Constrained Rewrite System)

`0(n, r) → `1(n, r,Nil)`1(n, r, xs) → `1(n− 1, r + 1,Cons(r, xs)) [n > 0]`1(n, r, xs) → `2(xs) [n == 0]

Possible rewrite sequence:

`0(2, 7)

→ `1(2, 7,Nil)

→ `1(1, 8,Cons(7,Nil))

→ `1(0, 9,Cons(8,Cons(7,Nil)))

→ `2(Cons(8,Cons(7,Nil)))

Here 7, 8, . . . are predefined constants.

33/48

Constrained Rewriting by Example

Consider a variation of the take-from program . . .

Example (Constrained Rewrite System)

`0(n, r) → `1(n, r,Nil)`1(n, r, xs) → `1(n− 1, r + 1,Cons(r, xs)) [n > 0]`1(n, r, xs) → `2(xs) [n == 0]

Possible rewrite sequence:

`0(2, 7)

→ `1(2, 7,Nil)

→ `1(1, 8,Cons(7,Nil))

→ `1(0, 9,Cons(8,Cons(7,Nil)))

→ `2(Cons(8,Cons(7,Nil)))

Here 7, 8, . . . are predefined constants.33/48

Papers on termination of imperative programs often about integers as data

Example (Imperative Program)

`0:

if (x ≥ 0)

`1:

while (x 6= 0)

`2:

x = x − 1;

Does this program terminate?

Example (Equivalent Translation to Constrained Rewriting,cf. [McCarthy, CACM ’60 ])

`0(x) → `1(x) [x ≥ 0]`1(x) → `2(x) [x 6= 0]`2(x) → `1(x− 1)`1(x) → `3(x) [x == 0]

Oh no! `1(−1)→ `2(−1)→ `1(−2)→ `2(−2)→ `1(−3)→ · · ·

⇒ Restrict initial states to `0(z) for z ∈ Z⇒ Find invariant x ≥ 0 at `1, `2 (exercise)

34/48



`0: if (x ≥ 0)`1: while (x 6= 0)`2: x = x − 1;



`0(x) → `1(x) [x ≥ 0]`1(x) → `2(x) [x 6= 0]`2(x) → `1(x− 1)`1(x) → `3(x) [x == 0]

Oh no! `1(−1)→ `2(−1)→ `1(−2)→ `2(−2)→ `1(−3)→ · · ·


34/48



`0: if (x ≥ 0)`1: while (x 6= 0)`2: x = x − 1;



`0(x) → `1(x) [x ≥ 0]`1(x) → `2(x) [x 6= 0]`2(x) → `1(x− 1)`1(x) → `3(x) [x == 0]

Oh no! `1(−1)→ `2(−1)→ `1(−2)→ `2(−2)→ `1(−3)→ · · ·

⇒ Restrict initial states to `0(z) for z ∈ Z

⇒ Find invariant x ≥ 0 at `1, `2 (exercise)

34/48



`0: if (x ≥ 0)`1: while (x 6= 0)`2: x = x − 1;



`0(x) → `1(x) [x ≥ 0]`1(x) → `2(x) [x 6= 0]`2(x) → `1(x− 1)`1(x) → `3(x) [x == 0]

Oh no! `1(−1)→ `2(−1)→ `1(−2)→ `2(−2)→ `1(−3)→ · · ·


34/48



`0: if (x ≥ 0)`1: while (x 6= 0)`2: x = x − 1;



`0(x) → `1(x) [x ≥ 0]`1(x) → `2(x) [x 6= 0 ∧ x ≥ 0]`2(x) → `1(x− 1) [x ≥ 0]`1(x) → `3(x) [x == 0 ∧ x ≥ 0]

Oh no! `1(−1)→ `2(−1)→ `1(−2)→ `2(−2)→ `1(−3)→ · · ·


34/48

Java Challenges

Java: object-oriented imperative language

sharing and aliasing (several references to the same object)side effectscyclic data objects (list.next == list)object-orientation with inheritance. . .

35/48

Java Example

Does count terminate for all inputs? Why (not)?

36/48

public class MyInt {

// only wrap a primitive intprivate int val;

// count "num" up to the value in "limit"public static void count(MyInt num, MyInt limit) {

if (num == null || limit == null) {return;

}// introduce sharingMyInt copy = num;while (num.val < limit.val) {

copy.val++;}

}}

Approach to Termination Analysis of Java

Tailor two-stage approach from Haskell analysis to Java [Otto et al, RTA ’10 ]

Back-end: From rewrite system to termination proofConstrained term rewriting with integers [Giesl et al, JAR ’17 ]

Termination techniques for rewriting and for integers can be integrated

Front-end: From Java to constrained rewrite systemBuild termination graph that over-approximates all runs of Javaprogram (abstract interpretation)Termination graph has invariants for integers and heap object shape(trees?)Extract rewrite system from termination graph

Implemented in the tool AProVE (→ web interface)


37/48


Java: Source Code vs Bytecode

[Otto et al, RTA ’10 ] describe their technique for compiled Java programs:Java Bytecode

desugared machine code for a (virtual) stack machine,still has all the (relevant) information from source codeinput for Java interpreter and for many program analysis toolssomewhat inconvenient for presentation, though . . .

Here: Java source code

38/48





38/48

00: aload_001: ifnull 804: aload_105: ifnonnull 908: return09: aload_010: astore_211: aload_012: getfield val15: aload_116: getfield val19: if_icmpge 3522: aload_223: aload_224: getfield val27: iconst_128: iadd29: putfield val32: goto 1135: return





38/48

Ingredients for the Abstract Domain

1 program counter value (line number)2 values of variables (treating int as reference type)3 over-approximating info on possible variable values

integers: use intervals, e.g. x ∈ [4, 7] or y ∈ [0, ∞]heap memory with objects, no sharing unless stated otherwiseMyInt(?): maybe null, maybe a MyInt object

Heap predicates:Two references may be equal: o1=

? o2Two references may share: o1%$o2Reference may have cycles: o1 !

03 | num : o1, limit : o2o1 : MyInt(?)o2 : MyInt(val = i1)i1 : [4, 80]

39/48

Building the Termination Graph

1 | num : o1, limit : o2o1 : MyInt(?)o2 : MyInt(?)

A

40/48

public class MyInt {private int val;static void count(MyInt num,

MyInt limit) {1: if (num == null2: || limit == null)3: return;4: MyInt copy = num;5: while (num.val < limit.val)6: copy.val++;7: } }



A

3 | num : o1, limit : o2o1 : nullo2 : MyInt(?)

B

2 | num : o1, limit : o2o1 : MyInt(val = i1)o2 : MyInt(?)i1 : (−∞,∞)

C

40/48





A


B


C

3 | num : o1, limit : o2o1 : MyInt(val = i1)o2 : nulli1 : (−∞,∞)

D

4 | num : o1, limit : o2o1 : MyInt(val = i1)o2 : MyInt(val = i2)i1 : (−∞,∞)i2 : (−∞,∞)

E

40/48





A


B


C


D


E

5 | num : o1, limit : o2, copy : o1o1 : MyInt(val = i1)o2 : MyInt(val = i2)i1 : (−∞,∞)i2 : (−∞,∞)

F

40/48





A


B


C


D


E


F

7 | num : o1, . . .. . .

G


H

40/48





A


B


C


D


E


F

7 | num : o1, . . .. . .

G


H


I

40/48



From Java to Termination Graphs

Termination Graphs

symbolic over-approximation of all computations (abstractinterpretation)expand nodes until all leaves correspond to program endsby suitable generalization steps, one can always get a finitetermination graphstate s1 is instance of state s2 if all concrete states described by s1are also described by s2

Using Termination Graphs for Termination Proofs

every concrete Java computation corresponds to a computation pathin the termination graph (for Haskell we called them DP paths)termination graph is called terminating iff it has no infinitecomputation path

41/48

Transformation Objects to Terms

16 | num : o1, limit : o2, foo : o3, bar : o4o1 : MyInt(?)o2 : MyInt(val = i2)o3 : nulli1 : (−∞,∞)i2 : (−∞,∞)o4 : MyList(?)o4 !

For every class C with n fields, introduce an n-ary function symbol C

term for o1: o1term for o2: MyInt(i2)

term for o3: nullterm for o4: x (new variable)

42/48


public class A {int a;

}

public class B extends A {int b;

}

...A x = new A();x.a = 1;

B y = new B();y.a = 2;y.b = 3;

for every class C with n fields,introduce (n+ 1)-ary function symbol Cfirst argument: part of the objectcorresponding to subclasses of Cterm for x:

jlO(

A(eoc, 1)

)

→ eoc for end of classterm for y:

jlO(

A(B(eoc, 3), 2)

)

every class extends Object! (→ jlO ≡java.lang.Object)

43/48


public class A {int a;

}

public class B extends A {int b;

}

...A x = new A();x.a = 1;

B y = new B();y.a = 2;y.b = 3;

for every class C with n fields,introduce (n+ 1)-ary function symbol Cfirst argument: part of the objectcorresponding to subclasses of Cterm for x: jlO(A(eoc, 1))→ eoc for end of classterm for y: jlO(A(B(eoc, 3), 2))every class extends Object! (→ jlO ≡java.lang.Object)

43/48

From the Termination Graph to Terms and Rules


F


H


I

i1 > i2

i3 = i1 + 1

State F: `F (jlO(eoc,MyInt(i1)), jlO(eoc,MyInt(i2)))

→

State H: `H(jlO(eoc,MyInt(i1)), jlO(eoc,MyInt(i2)), jlO(eoc,MyInt(i1)))

[i1 < i2]

State H: `H(jlO(eoc,MyInt(i1)), jlO(eoc,MyInt(i2)))

→

State I: `F (jlO(eoc,MyInt(i1 + 1)), jlO(eoc,MyInt(i2)), jlO(eoc,MyInt(i1 + 1)))

Termination easy to show

44/48



F


H


I

i1 > i2

i3 = i1 + 1

State F: `F (jlO(eoc,MyInt(i1)), jlO(eoc,MyInt(i2)))

→

State H: `H(jlO(eoc,MyInt(i1)), jlO(eoc,MyInt(i2)), jlO(eoc,MyInt(i1))) [i1 < i2]

State H: `H(jlO(eoc,MyInt(i1)), jlO(eoc,MyInt(i2)))

→



44/48



F


H


I

i1 > i2

i3 = i1 + 1

State F: `F (jlO(eoc,MyInt(i1)), jlO(eoc,MyInt(i2)))→

State H: `H(jlO(eoc,MyInt(i1)), jlO(eoc,MyInt(i2)), jlO(eoc,MyInt(i1))) [i1 < i2]

State H: `H(jlO(eoc,MyInt(i1)), jlO(eoc,MyInt(i2)))→



44/48

Extensions

modular termination proofs and recursion[Brockschmidt et al, RTA ’11 ]

proving reachability and non-termination (uses only terminationgraph) [Brockschmidt et al, FoVeOOS ’11 ]

proving termination with cyclic data objects (preprocessing intermination graph) [Brockschmidt et al, CAV ’12 ]

proving upper bounds for time complexity (abstracts terms tonumbers) [Frohn and Giesl, iFM ’17 ]

45/48

Conclusion Part II

Successful empirical evaluation of Java approach on TerminationProblems Database, including Java classes (e.g., LinkedList)Approach also successful at Termination Competition (other tools likeCOSTA, Julia abstract data structures to numbers instead of terms)Common theme for program analysis by rewriting: handlelanguage-specifics in front-end, transitions between program statesbecome rewrite rules for TRS termination back-endHaskell: single term as abstract domain to represent program stateJava: more complex abstract domain, use constrained rewriting

46/48

Exercises I

Question 1

Recall the imperative program fragment on slide 34 (the while loopcounting down).

In the lecture we added the invariant x ≥ 0 to the constrained rewritesystem. Construct a termination graph for the program that also finds thisinvariant and extract a constrained rewrite system with the invariant fromthis termination graph.

47/48

Exercises II

Question 2

public class List {private List next;

public static int length(List xs) {int res = 0;while (xs != null) {

xs = xs.next;res++;

}return res;

}}

Construct a termination graph for length, then extract the correspondingconstrained rewrite system for the SCCs in the graph.Can you prove termination of the resulting constrained rewrite system?

48/48

References I

T. Arts and J. Giesl. Termination of term rewriting using dependencypairs. Theoretical Computer Science, 236(1-2):133–178, 2000.

M. Brockschmidt, C. Otto, and J. Giesl. Modular termination proofs ofrecursive Java Bytecode programs by term rewriting. In RTA ’11,pages 155–170, 2011.

M. Brockschmidt, R. Musiol, C. Otto, and J. Giesl. Automatedtermination proofs for Java programs with cyclic data. In CAV ’12,pages 105–122, 2012a.

M. Brockschmidt, T. Ströder, C. Otto, and J. Giesl. Automateddetection of non-termination and NullPointerExceptions for JavaBytecode. In FoVeOOS ’11, pages 123–141, 2012b.

P. Cousot and R. Cousot. Abstract interpretation: a unified latticemodel for static analysis of programs by construction or approximationof fixpoints. In POPL ’77, pages 238–252, 1977.

49/48

References II

S. Falke and D. Kapur. A term rewriting approach to the automatedtermination analysis of imperative programs. In CADE ’09, pages277–293, 2009.

F. Frohn and J. Giesl. Complexity analysis for Java with AProVE. IniFM 17, 2017. To appear.

C. Fuhs, J. Giesl, M. Plücker, P. Schneider-Kamp, and S. Falke.Proving termination of integer term rewriting. In RTA ’09, pages32–47, 2009.

J. Giesl, R. Thiemann, P. Schneider-Kamp, and S. Falke. Mechanizingand improving dependency pairs. Journal of Automated Reasoning, 37(3):155–203, 2006.

J. Giesl, M. Raffelsieper, P. Schneider-Kamp, S. Swiderski, andR. Thiemann. Automated termination proofs for Haskell by termrewriting. ACM TOPLAS, 33(2):1–39, 2011.

50/48

References III

J. Giesl, T. Ströder, P. Schneider-Kamp, F. Emmes, and C. Fuhs.Symbolic evaluation graphs and term rewriting: A general methodologyfor analyzing logic programs. In PPDP ’12, pages 1–12, 2012.

J. Giesl, C. Aschermann, M. Brockschmidt, F. Emmes, F. Frohn,C. Fuhs, J. Hensel, C. Otto, M. Plücker, P. Schneider-Kamp,T. Ströder, S. Swiderski, and R. Thiemann. Analyzing programtermination and complexity automatically with AProVE. Journal ofAutomated Reasoning, 58(1):3–31, 2017.

C. Kop and N. Nishida. Term rewriting with logical constraints. InFroCoS ’13, pages 343–358, 2013.

J. McCarthy. Recursive functions of symbolic expressions and theircomputation by machine, part I. Commun. ACM, 3(4):184–195, 1960.

51/48

References IV

C. Otto, M. Brockschmidt, C. v. Essen, and J. Giesl. Automatedtermination analysis of Java Bytecode by term rewriting. In RTA ’10,pages 259–276, 2010.

P. Schneider-Kamp, J. Giesl, A. Serebrenik, and R. Thiemann.Automated termination proofs for logic programs by term rewriting.ACM TOCL, 11(1):1–52, 2009.

F. van Raamsdonk. Translating logic programs into conditionalrewriting systems. In ICLP ’97, pages 168–182, 1997.

52/48

proving program termination via term...

Documents