We consider the system Applicative_05__ReverseLastInit. Alphabet: compose : [a -> a * a -> a] --> a -> a cons : [a * a] --> a hd : [] --> a -> a init : [] --> a -> a last : [] --> a -> a nil : [] --> a reverse : [] --> a -> a reverse2 : [a * a] --> a tl : [] --> a -> a Rules: compose(f, g) x => g (f x) reverse x => reverse2(x, nil) reverse2(nil, x) => x reverse2(cons(x, y), z) => reverse2(y, cons(x, z)) hd cons(x, y) => x tl cons(x, y) => y last => compose(hd, reverse) init => compose(reverse, compose(tl, reverse)) This AFS is converted to an AFSM simply by replacing all free variables by meta-variables (with arity 0). We use the dependency pair framework as described in [Kop12, Ch. 6/7], with static dependency pairs (see [KusIsoSakBla09] and the adaptation for AFSMs and accessible arguments in [Kop13]). In order to do so, we start by eta-expanding the system, which gives: compose(F, G, X) => G (F X) reverse(X) => reverse2(X, nil) reverse2(nil, X) => X reverse2(cons(X, Y), Z) => reverse2(Y, cons(X, Z)) hd(cons(X, Y)) => X tl(cons(X, Y)) => Y last(X) => compose(/\x.hd(x), /\y.reverse(y), X) init(X) => compose(/\x.reverse(x), /\y.compose(/\z.tl(z), /\u.reverse(u), y), X) We thus obtain the following dependency pair problem (P_0, R_0, static, formative): Dependency Pairs P_0: 0] reverse#(X) =#> reverse2#(X, nil) 1] reverse2#(cons(X, Y), Z) =#> reverse2#(Y, cons(X, Z)) 2] last#(X) =#> compose#(/\x.hd(x), /\y.reverse(y), X) 3] last#(X) =#> hd#(Y) 4] last#(X) =#> reverse#(Y) 5] init#(X) =#> compose#(/\x.reverse(x), /\y.compose(/\z.tl(z), /\u.reverse(u), y), X) 6] init#(X) =#> reverse#(Y) 7] init#(X) =#> compose#(/\x.tl(x), /\y.reverse(y), Y) 8] init#(X) =#> tl#(Y) 9] init#(X) =#> reverse#(Y) Rules R_0: compose(F, G, X) => G (F X) reverse(X) => reverse2(X, nil) reverse2(nil, X) => X reverse2(cons(X, Y), Z) => reverse2(Y, cons(X, Z)) hd(cons(X, Y)) => X tl(cons(X, Y)) => Y last(X) => compose(/\x.hd(x), /\y.reverse(y), X) init(X) => compose(/\x.reverse(x), /\y.compose(/\z.tl(z), /\u.reverse(u), y), X) Thus, the original system is terminating if (P_0, R_0, static, formative) is finite. We consider the dependency pair problem (P_0, R_0, static, formative). We place the elements of P in a dependency graph approximation G (see e.g. [Kop12, Thm. 7.27, 7.29], as follows: * 0 : 1 * 1 : 1 * 2 : * 3 : * 4 : 0 * 5 : * 6 : 0 * 7 : * 8 : * 9 : 0 This graph has the following strongly connected components: P_1: reverse2#(cons(X, Y), Z) =#> reverse2#(Y, cons(X, Z)) By [Kop12, Thm. 7.31], we may replace any dependency pair problem (P_0, R_0, m, f) by (P_1, R_0, m, f). Thus, the original system is terminating if (P_1, R_0, static, formative) is finite. We consider the dependency pair problem (P_1, R_0, static, formative). We will use the reduction pair processor with usable rules [Kop12, Thm. 7.44]. (P_1, R_0) has no usable rules. It suffices to find a standard reduction pair [Kop12, Def. 6.69]. Thus, we must orient: reverse2#(cons(X, Y), Z) >? reverse2#(Y, cons(X, Z)) We orient these requirements with a polynomial interpretation in the natural numbers. The following interpretation satisfies the requirements: cons = \y0y1.3 + 2y1 + 3y0 reverse2# = \y0y1.3y0 Using this interpretation, the requirements translate to: [[reverse2#(cons(_x0, _x1), _x2)]] = 9 + 6x1 + 9x0 > 3x1 = [[reverse2#(_x1, cons(_x0, _x2))]] By the observations in [Kop12, Sec. 6.6], this reduction pair suffices; we may thus replace a dependency pair problem (P_1, R_0) by ({}, R_0). By the empty set processor [Kop12, Thm. 7.15] this problem may be immediately removed. As all dependency pair problems were succesfully simplified with sound (and complete) processors until nothing remained, we conclude termination. +++ Citations +++ [Kop12] C. Kop. Higher Order Termination. PhD Thesis, 2012. [Kop13] C. Kop. Static Dependency Pairs with Accessibility. Unpublished manuscript, http://cl-informatik.uibk.ac.at/users/kop/static.pdf, 2013. [KusIsoSakBla09] K. Kusakari, Y. Isogai, M. Sakai, and F. Blanqui. Static Dependency Pair Method Based On Strong Computability for Higher-Order Rewrite Systems. In volume 92(10) of IEICE Transactions on Information and Systems. 2007--2015, 2009.