Automated Termination Analysis for Haskell: From Term Rewriting to Programming Languages

Abstract

Abstract. There are many powerful techniques for automated termination analysis of term rewriting. However, up to now they have hardly been used for real programming languages. We present a new approach which permits the application of existing techniques from term rewriting in order to prove termination of programs in the functional language Haskell. In particular, we show how termination techniques for ordinary rewriting can be used to handle those features of Haskell which are missing in term rewriting (e.g., lazy evaluation, polymorphic types, and higherorder functions). We implemented our results in the termination prover AProVE and successfully evaluated them on existing Haskell-libraries.

Termination of narrowing via termination of rewriting

“…Another related application is concerned with the termination analysis of Haskell programs introduced in [33]. In this work, a restricted form of partial evaluation based on a narrowing-like mechanism is used to encode the lazy strategy of Haskell.…”

“…We note that, although current functional logic languages like Curry [27] and Toy [50] consider some narrowing strategy (i.e., some variant of lazy narrowing [20,54,59] like needed narrowing [8]), our termination analysis techniques provide a sufficient condition for the termination of these programs. Moreover, it would not be difficult to extend our approach following the ideas in [33] in order to get more accurate results. Termination analysis is also essential for ensuring the finiteness of partial evaluation [44].…”

Proving Termination of Integer Term Rewriting

“…This is not a severe restriction as innermost termination is equivalent to full termination for non-overlapping TRSs and moreover, many programming languages already have an innermost evaluation strategy. Even for lazy languages like Haskell, with the translation of programs to TRSs in [14], it suffices to show innermost termination. 7 Of course, one could easily include additional junctors like ∨ or ¬ in BoolOp.…”

“…But the desired interpretation SUM Pol = x 1 − x 2 cannot be used, because in DP (8), the defined symbol + occurs in the second argument of SUM which is not a Pol -increasing position. 14 To avoid the need for considering infinitely many rules in the reduction pair processor and in order to handle ITRSs where defined symbols like + occur on non-increasing positions, we will now restrict ourselves to so-called Iinterpretations where we fix the max-polynomials that are associated with the pre-defined symbols from Z ∪ ArithOp. The definition of I-interpretations guarantees that we have ℓ ≈ Pol r for all rules ℓ → r ∈ PD where root(ℓ) ∈ {+, −, * }.…”

“…e.g. [14,27]. The advantage of rewrite techniques is that they are very powerful for algorithms on user-defined data structures, since they can automatically generate suitable well-founded orders comparing arbitrary forms of terms.…”