Content uploaded by Christoph Walther
Author content
All content in this area was uploaded by Christoph Walther on Apr 23, 2017
Content may be subject to copyright.
CHRISTOPH WALTHER
CRITERIA FOR TERMINATION
1. INTRODUCTION
Proving the termination of algorithms is one of the challenges in program veriﬁca
tion. Termination proofs can be quite complicated, e.g. proving the termination of
McCarthy’s 91function
function
if then
else
ﬁ
or Takeuchi’s function
function
if then
else
ﬁ
require a sophisticated argumentation, cf. (Manna, 1974; Moore, 1979; Feferman,
1991; Knuth, 1991), and for other algorithms as e.g.
function
if then
else if then
else
ﬁ
ﬁ
(attributed to Collatz) termination is an open problem for more than 50 years (Gardner,
1983). On the other hand, proof procedures exist which verify the termination of
“standard” procedures for arithmetic functions, as e.g.
1
CHRISTOPH WALTHER
function
if then
else if then
else if then
else
ﬁ
ﬁ
ﬁ
for sorting, or for operations on trees and graphs etc. without any human advice
(Walther, 1994b; Giesl, 1995; Giesl et al., 1998). Hence terminationcan be proved in
a uniform way in some cases at least.
In this paper we illustrate which problems must be solved for proving the termi
nation of an algorithm. We formulate some sufﬁcient criteria and demonstrate their
success and failure by examples. We also deﬁne classes of algorithms by simple
syntactic requirements, whose termination usually is easier to verifycompared to the
general case.
Informally,the termination of an algorithmmeans that each computation involving
the algorithm halts after ﬁnitely many steps. A computation of a machine Mis
modelled by a function which maps expressions of a program into values of the
machine. The function is called the interpreter of Mand is formally given as
a partial function EXPR VAL, where VAL is the set of all values of Mand
EXPR denotes the set of expressions of a program , consisting of calls of procedures
deﬁned by as well as calls of base operations provided by the machineM.
We need some syntax to represent values,expressions and programs, and we use
standard notions of predicate logic, cf. e.g. (Gallier, 1986), and term rewriting, cf.
e.g. (Avenhaus, 1995; Baader and Nipkow, 1998), for that purpose. In particular, we
write for the set of manysorted terms of sort over some sorted signature
for function symbols, a set of variable symbols and a set of sort symbols, where
throughout the paper. abbreviates the set of all ground terms
of sort . We sometimes write terms as strings, i.e. is written instead of
, and we use etc. as a shorthand notation for the cartesian
product , where .
For sake of simplicity, we assume a machine Mwhich operates on natural num
bers and boolean values only. Natural numbers are represented by the nullary base
operation (for zero) and the unary base operation denoting the successor
function. So natural numbers are formally given by the set = ,
, , of ground terms over and and we use ,
as the set of boolean values. Subsequently, we write as an abbrevi
ation for , as an abbreviation for , , and we use
instead of VAL to denote the set of all values onwhich Moperates.
CRITERIA FOR TERMINATION
The machine Moffers 4 additional base operations, viz. the predecessor operation
, a test operation , and two conditionals
, where . M):= , , , , , , ,
is the set of all names of base operations known to the machine M.
We now extend our development by a concept for functional programs to be exe
cuted by M:Afunctional procedure is an expression of the form function ( : ,
, : ): such that the formal parameters of are distinct vari
ables of sort respectively and the body of is a term of sort containing
only variable symbols from .
A sequence of functional procedures function is a
functional program iff for each the body of contains only func
tion symbols from M. Due to this requirement, each functional
procedure is deﬁned only by using base operations, by previously deﬁned pro
cedures , and by recursion,as may occur in the body of . Note
that our requirement for functional programs excludes mutual recursion. We let ( )
denote the set of all names of base operations plus all names of operations deﬁned
by a functional program , i.e. M. Hence the set
of ground terms represents the set of expressions EXPR of
the functional program , to be evaluated by the interpreter to the values of M.
For instance, is a functional program, where the functional procedure
is deﬁned as
function
To ease readability, we use abbreviations like “ ” for “ ”, “ ” for
“ ”, “if then else ﬁ” for “ ”, “ ” for “ ” and
“ ” for “ ”. We also use the standard mathematical notation for function
symbols if appropriate. E.g.
function
if then
else
ﬁ
deﬁnes a functional procedure and
function
if then
else if then
else
ﬁ
ﬁ
CHRISTOPH WALTHER
deﬁnes a procedure in a more readable notation, and is a
functional program.
2. OPERATIONAL SEMANTICS AND TERMINATION
Having deﬁned the syntax of the kind of functional programswe are concerned with,
we now provide a semantics for these programs. This is achieved by deﬁning a so
called evaluation calculus, i.e. a calculus whose inference rules stipulate how an
expression from is transformed step by step, such that eventually a value
from is obtained (sometimes):
Deﬁnition 1 (Evaluation Calculus for M)
Let , , , , .
Then the evaluation calculus for the machine Mis given by the following inference
rules:
where is a substitution deﬁned as
.
We call the evaluation relation of M, where holds iff some inference rule
exists, such that the application requirement is satisﬁed.
The terms in rule (11) are the actual parameters of the procedure
call . Here procedure calls are implemented by the parameter passing
discipline callbyname (sometimes also called callbyneed), and the corresponding
evaluation strategy is called lazy evaluation. This is because an actual parameter only
is evaluated if its value really is required for the evaluation of a procedure call, cf.
Section 4 .
CRITERIA FOR TERMINATION
We use the evaluation calculus to compute values from expressions of a functional
program, and e.g. is obtained by an evaluation of the procedure call ,
because .
The evaluation relation is deterministic and all values are minimal w.r.t. .
In addition, is well founded (or noetherian), if restricted to expressions from
M:
Theorem 2
For all :
(i) ,if ,
(ii) iff for some , and
(iii) ( M, ) is a wellfounded set.
Proof: (i), (ii) By structural induction upon . (iii) If and M, then
has strictly less symbols than , as proved by structural inductionupon .
As a consequence of Theorem 2, for each expression at most one
value exists, such that . Hence we deﬁne the interpreter of Mas
the partial function : satisfying iff . This
means that the machine Mcomes up with the result , as e.g. , if called with an
expression , as e.g. , provided the evaluation of succeeds.
The interpreter only is a partial function, since by the rule for procedure
calls, ( , ) generally is not a wellfounded set. For instance,
may rise an inﬁnite evaluation
of . This means that the eval
uation of does not succeed, and we write in such a
case.
However, the interpreter is a total function if restricted to expressions from the
empty program. So a nonvalue expression always can be evaluated, if consists
of calls to base operations only, cf. Theorem 2(iii). For certain functional programs,
as e.g. , this property may also hold, and we call a functional
program terminating, if inﬁnite evaluations are impossible:
Deﬁnition 3 (Termination of Functional Programs)
A functional program terminates iff ( , ) is a wellfounded set.
Since our development excludes mutual recursion, the termination of a functional
program can be expressed by a notion of termination forfunctional procedures:
Deﬁnition 4 (Termination of Functional Procedures)
Let be a functional program, such that terminates. Then the
functional procedure terminates iff terminates.
CHRISTOPH WALTHER
By this deﬁnition, the termination of a functional program can
be proved by considering the functional procedures of step by step, starting from
the empty program. All we need is a requirement for the termination of a functional
procedure , where we may already assume the termination of the other functional
procedures called in the body of .
Subsequently we aim to develop some criteria for the termination of functional
procedures in order to gain some insights into the difﬁculty of provingthe termination
of functional programs.
3. DENOTATIONAL SEMANTICS OF FUNCTIONAL
PROGRAMS
Denotational semantics provide an alternative approachto the operational semantics
of functional programs deﬁned by the interpreter . Since denotational semantics
uses semantical notions of ﬁrstorder predicate logic, it is in particular useful for our
purpose: For each functional program , we consider a ( )algebra ,
where the carrier of is separated into the sets and
. Thismeansthatthecarrierof consistsofthevaluesofthe
machine Mplus two symbols denoting undeﬁnedness for each sort. The interpretation
function associates each function symbol from with
a (total) monotonic function .
In case of base operations , is explicitly given, as e.g. the interpretation of
is deﬁned by , and
. “respects” the values of M, i.e. , if
, and . For function symbols which are introduced by a
functional procedure , is deﬁned as the least ﬁxpoint of the functional obtained
from , see e.g. (Manna, 1974).
As usual, we write ( ) for the interpretation of an expression by
. In denotational semantics, nontermination of functional procedures is modelled
by the symbols for undeﬁnedness, as e.g. for all . More
generally, the relation between operational and denotational semantics is expressed by
the following theorem:
Theorem 5 (Equivalence of Operational and Denotational Semantics)
Either or and for each functional program
and each .
By Theorem 5, the denotational semantics of functional programs can be deﬁned
in such a way, that the interpretation ( )of corresponds to the result ofevaluating
by iff such an evaluation succeeds, and is interpreted as “undeﬁned” otherwise.
CRITERIA FOR TERMINATION
4. CALLBYNAME TERMINATION
Let and let be a functional program,
such that terminates. Then does not terminate, if there is an inﬁnite sequence S
of expressions , , , such that the evaluation of leads to the
evaluationof for all . On the contrary,ifeachcall of necessitates
onlyﬁnitely many recursive calls, say , , , then terminates, because the
evaluation ofthe last recursive call necessitates calls of proceduresfrom
the terminating functional program at most. Consequently, proving termination of
requires proving the absence of an inﬁnite sequence of recursive calls like Sabove.
Thekeypointin the deﬁnition of Sis the requirement “theevaluationof leads
to the evaluation of ”. This requirement is formally captured by the notion of
anecessary subevaluation: Let denote the set of all occurrences (or positions)
of a term (including the “trivial” occurrence ) and let denote the subterm of
at occurrence . Then we write for a nonvalue expression of a
functional program and some iff the evaluation of by necessitates
the evaluation of the subterm :
Deﬁnition 6 (Necessary Subevaluation )
Let be a functional program, and . Then the
evaluation of necessitates the evaluation of , in symbols ,iff or
and
(i) and ,or
(ii) , and ,or
(iii) , and ,or
(iv) and for
some such that and .
By (i), the ﬁrst argument of an application of a base operation must
always be evaluated if is to be evaluated. The only exception from this
rule are terms of form , as those terms already represent values,
and consequently no further evaluation is needed (and possible). The evaluation of
the thenpart of a conditional is only necessary, if the condition
evaluates to , cf. (ii), and the evaluation of the elsepart is required, if
evaluates to , cf. (iii). This entails in particular, that no branch of the conditional
is considered, if the evaluation of fails by nontermination. Finally, an actual
parameter must be evaluated on the evaluation of a procedure call ,
if the instantiated procedure body is evaluated at some occurrence , where
selects the formal parameter in the (noninstantiated) procedure body , cf. (iv)
and Figure 1.
CHRISTOPH WALTHER
={... xiti...}σwhere /
xi
RfRf
σ()
1
ttn
ti
ti
ft
1tn
1in
iff
and
ξξ
( , ... , )
Figure 1 Necessary subevaluations of actual parameters
The notion of a necessary subevaluation mirrors the lazy evaluation strategy im
plemented by the interpreter , because for the evaluation of an expression , only
subterms with are considered. Lemma 7 illustrates the relation between
necessary subevaluations and the interpreter :
Lemma 7
For all :
iff and for some , cf. Figure 2.
Proof: The onlyif case is obvious, and the ifcase is proved byNoetherian induction
upon the length of the evaluation sequence of .
To investigate the termination of a functional procedure
which is added to a terminating functional program
yielding , we consider a certain ( )algebra : The
interpretation function of ( ) coincides with the interpretation function of
the ( )algebra for the function symbols from ( ), i.e. for all
CRITERIA FOR TERMINATION
( ), and for some function . In other words, ( )
givesameaningtoallfunctionsymbolsfrom ( ) suchthatthefunctionsymbolsfrom
( ) are associated with the (total) function computed by , cf. Theorem 5, and
is associated with some arbitrary monotonic function . Using the notion of necessary
subevaluations and the ( )algebra ( ), now a criterion for the termination of a
functional procedure can be formulated:
*∝
*∝
iff ∃π
tt
π
tπ

Figure 2 Evaluation of expressions andnecessary subevaluations
Deﬁnition 8 (callbyname Termination)
A functional procedure terminates “callbyname” iff some wellfounded relation
and some function exists, such that
(i) for all with and for all
with and , and
(ii) satisﬁes , i.e. .
For each procedure call , callbyname termination demands that the interpre
tation ( ) of the parameter list which belongs to an executed recursive
call has to be smaller w.r.t. some wellfounded relation than the interpreta
tion ( ) of the argument list belongingto the initial procedure call . The
interpretation of the arguments is ﬁxed by the semantics of , except for the func
tion symbol of the functional procedure whose termination is under investigation.
However, by requirement (ii) one may assume that the interpretation of is “com
patible” with the deﬁnition of , when proving (i). In other words, determines the
CHRISTOPH WALTHER
sequences Sof procedure calls , , , to be considered and guarantees
that these sequences are ﬁnite, where is used to verify that the arguments , , ,
of the procedure calls in Sare ordered w.r.t. .
Theorem 9
A functional procedure terminates iff terminates callbyname.
Proof: Let suchthat iffsome exist
suchthat andtheevaluationof leadstotheevaluation
of . Then is well founded, because by the termination of , each
sequence of recursive calls necessitated by a procedure call is ﬁnite. We choose
, i.e. is the function computed by , therefore , and
satisﬁes .Nowif and , then the evaluation of leads to the
evaluationof , hence , and terminatescallbyname.
Let and for each
with , and let , such that is minimal
among all elements of . Then , because , where
. Since terminates, has a subterm such that
and for some .
Let such that iff and
for some . Then is a proper subtermof if , hence
is well founded and we prove by Noetherian induction upon .
Since , cannot be a proper subterm of , hence
implies , where for some . Conse
quently , because terminates callbyname,
contradicting the minimality of ( ), and therefore .
Now if for some , then there must be a smallest
procedure call with , i.e. for each .
But then , hence for any and terminates.
Example 10
(i) The functional procedure deﬁned as
function
if then
else
ﬁ
terminatescallbyname: Let suchthat satisﬁes . Then
(*) “ implies for all and for all ”, as it is
easily veriﬁed by Peano induction upon .
A procedure call necessitates the evaluation of the recursive calls (
) and . Let iff
and either or . We ﬁnd for some
CRITERIA FOR TERMINATION
whenever the evaluation of leads to a recursive call. Hence ,
because satisﬁes , and therefore . So we obtain
.
If , then
. Otherwise , cf. (*), hence
, and require
ment 8(i) is satisﬁed for the ﬁrst recursive call. Since
, requirement 8(i) is satisﬁed also forthe other
recursive call. Since no other recursive calls are necessitated by the evaluation of
, terminates callbyname.
(ii) The functional procedure
does not terminate callbyname: Each procedure call necessitates
the evaluation of the recursive call and there is no wellfounded relation
satisfying .
Example 10(i) illustrates the problemsto be solved if callbyname termination of
a functional procedure has to be veriﬁed: First, one has to “guess” a wellfounded
relation which is useful for the termination proof. Then, one has to determine the
recursive calls in the body of the procedure,which are not executed (for a given input).
Finally, one has to invent a useful partial correctness statement about the functional
procedure,like(*)above,inordertoverifyrequirement8(i)fortheremainingrecursive
calls.
Since ,wemayalternativelydemand instead
of and “ satisﬁes ” in Deﬁnition 8, such that Theorem 9
still holds. However, this would demand to guess the semantics of a functional
procedure for proving its termination in any case, which is generally not required.
E.g. in Example 10 we have guessed the semantics of by the partial correctness
statement (*), since (*) stipulates that always evaluates to , provided the
evaluation succeeds at all. However, we may alternatively use the weaker statement
“ implies for all and all ” for
proving the termination of , which also holds for each satisfying . And
for other functional procedures, no reasoning about the semantics of is required at
all for proving ’s termination, cf. Section 7. But generally some reasoning about the
semantics of a functional procedure is inevitable for provingits termination.
The wellfounded relation of Deﬁnition 8 is deﬁned on , so values can be
compared with the undeﬁnedness symbol in particular. This looks odd at a ﬁrst
glance, since termination entails the absence of undeﬁnedness, cf. Theorem 5. By
Theorem 9, we can always ﬁnd a wellfounded relation deﬁned on , such that
the requirements of callbyname termination are satisﬁed and Theorem 9 still holds.
However, this stronger demand would yield harder proof obligations in some cases as
generally one has to verify in addition.
In Example 10(i), for instance, we would have to prove in addition, that the
interpretation of is never in the recursive case, because
otherwise ( ) cannot be compared with ( ),
CHRISTOPH WALTHER
as is now deﬁned on . So we had to verify (**) “ for all
and all ” too.
Hence using a wellfounded relation deﬁned on may ease a termination
proof considerably, as e.g. a direct proof of a statement like (**) is not required (but
implicitly obtained), howeverfor the price of a more difﬁcult proof of Theorem9.
5. CALLBYVALUE TERMINATION
The criterion of Deﬁnition 8 is not a very practical tool for proving the termination
of a functional procedure, and it seems worthwhile to relax the requirements a bit
in order to obtain a more handy recipe. Besides the problem to “guess” a useful
wellfounded relation and a partial correctness statement about carrying the
proof of 8(i), the main obstacle in applying callbyname termination is the problemto
determinewhethersomerecursivecall inthe bodyof in fact is executedonthe
evaluation of a procedure call . A remedy to this problem is to replace
in Deﬁnition 8 by a weaker requirement, which however is easier to decide.
To this effect, we associate with each subterm of a term a quantiﬁerfree
formulaCOND( , ), which must be satisﬁed whenever isevaluatedontheevaluation
of , i.e. whenever holds: Let be a subtermtree for , i.e. a tree whose
nodes are labelled with terms such that the root is labelled with and each node
with label has sons labelled with respectively. To compute
COND( , ), we also provide some of the vertices in with labels: For a node
labelled with , the vertexto the son with label is labelled with
and the vertex to the son with label receives the label . All other vertices
in carry no label. Now we obtain COND( , ) by forming a conjunction from the
set of all vertex labels on the path in from the root to the node labelled with
(where COND TRUE if this set is empty), cf. Figure 3.
E.g. COND and
COND for like
in Figure 3. Subsequently, we write COND TRUE iff COND TRUE
or COND and for each .
COND( , ) provides requirements in form of equations which must be satisﬁed, if
is to be evaluated for the evaluation of :
Lemma 11
For all and all :
If , then COND TRUE.
Proof: By structural induction upon .
By Lemma 11 and Theorem 5, COND is necessary for , and now
weconsiderallrecursivecalls suchthat COND ,
instead of , for proving the termination of a functional procedure :
CRITERIA FOR TERMINATION
zero(x) true zero(x) false
ge(x,y) true ge(x,y) false
......
=
=
=
=
=
=
=
=
zero(y) true
=
=
...
gcd(x,yx)
=
=
...
zero(x)
...
zero(y)
gcd(xy,y)ge(x,y) if(zero(x),y,gcd(x,yx))
zero(y) false
if(ge(x,y),gcd(xy,y),if(zero(x),y,gcd(x,yx)))x
if(zero(y),x,if(ge(x,y),gcd(xy,y),if(zero(x),y,gcd(x,yx))))
y
Figure 3 Labelled subterm tree ( ) for the computation of ( , )
Deﬁnition 12 (callbyvalue Termination)
A functional procedure terminates “callbyvalue” iff some wellfounded relation
and some function exists, such that
(i) for all with and for all
with and COND , and
(ii) satisﬁes , i.e. .
For each procedure call , callbyvaluetermination demands that the interpreta
tion of the parameter list which belongs to an executable recursive
call has to be smaller w.r.t. some wellfounded relation than the argument
list belonging to the initial procedure call .
Since entails COND ,callbyvalue termination
entails (callbyname) termination:
Theorem 13
If terminates callbyvalue, then terminates (callbyname).
CHRISTOPH WALTHER
Proof: Assumethat doesnotholdforsome
and some such that and , where .
Let such that iff is a proper subterm
of . Then is well founded, and we may assume that is minimal. Hence
and , because terminates. If , then
COND by Lemma 11, hence COND because
. But then COND where , hence
, because terminates callbyvalue, and with
a contradiction is obtained.
Example 14
(i) The functional procedure deﬁned as
function
if then
else if then
else if then
else
ﬁ
ﬁ
ﬁ
terminates callbyvalue: Let such that satisﬁes . Then
(*) “ implies or for all ”, as it is easily veriﬁed
by a twostep Peano induction. For a procedure call , the recursive calls
and have to be considered:
If , then .If
, then , hence by (*).
Consequently also is true, and we obtain .
Hence requirement 12(i) is satisﬁed for both recursive calls, terminates call
byvalue.
(ii) The functional procedure deﬁned as
function
if then
else
ﬁ
terminates callbyvalue: Let such that satisﬁes . Then
(*) “ implies for all ”, as it is easily veriﬁed by Peano
inductionupon . Foraprocedurecall ,therecursivecalls
and have to be considered:
CRITERIA FOR TERMINATION
Let be the wellfounded relation deﬁned by iff and either
or .If , then .If
, then , and if , then
by (*), hence also in this case. Since
requirement 12(i) is satisﬁed for both recursive calls, terminates callbyvalue.
Callbyvaluetermination is easier to verify than callbyname termination, simply
because it has not to be determined whether an executable recursive call will be
executed in fact. As a consequence, however,callbyvalue termination only provides
a sufﬁcient termination requirement, as there are terminating functional procedures,
which do not terminate callbyvalue:
Example 15
The (terminating) functional procedure from Example 10 does not terminate
callbyvalue, since there is no wellfounded relation such that for
some . In other words, does not terminate callbyvalue, because the
body of contains a recursive call , which results in nontermination,
if executed. However, since is never executed, this recursive call does not
spoil the (callbyname) termination of .
However, callbyvalue termination equivalently characterizes the successful eval
uation of each term, if procedure calls in a functional program are implemented by
the parameter passing discipline callbyvalue(instead of the callbynamediscipline).
The corresponding evaluation strategy is called eager evaluation and is obtained by
restricting all actual parameters in rule(11) ofthe evaluation calculus (cf. Deﬁnition 1)
to be values only, yielding
For procedure calls with nonvalue arguments, a further evaluation rule is provided,
viz.
where we write instead of , to distinguish eager evaluation from lazy evaluation.
For instance, the procedure call is evaluated to also by eager evaluation,
i.e. .
By presence of rule (12), the eager evaluation relation cannot be deterministic.
However a weaker conﬂuence requirement is guaranteed (and also all values are
minimal w.r.t. ):
Theorem 16
For all :
(i) iff for some , and
CHRISTOPH WALTHER
(ii) or for some ,if .
Proof: By structural induction upon .
As a consequence of Theorem 16, for each expression at most one
value exists, such that . Hence eager evaluation of expressions can be
modelled by a partial function  , called the eager interpreter
of , such that  iff . Now since eager evaluation demands the
evaluation of the actual parameters before the procedure deﬁnition is applied, actual
parameters are evaluated also if their values do not contribute to the result, and this
may cause nontermination in cases where lazy evaluationsucceeds.
Theorem 17
 for all iff terminates callbyvalue and 
for all .
Proof: If is to be evaluated by the eager interpreter  and
COND for some , then must be evaluated by  . Hence
the proof is similar to the proof of Theorem 9, where is replaced by
COND .
Let  , and let a minimal element
of . Then  , because , where . Since
 for all , has a subterm such that
COND TRUE and  for some .
We may assume, that is the smallest of those terms, i.e. all proper
subterms of can be evaluated by  , provided  evaluates the
CONDformula for to TRUE. Then  for some ,
since  for all . Consequently and
COND , hence , because terminates byvalue,
contradicting the minimality of .
Hence  for all and since  for all
,  for all .
Like in the deﬁnition of callbyname termination, the wellfounded relation
used for callbyvalue termination also is deﬁned on , yielding the same beneﬁts
as for callbyname termination: If had been demanded instead, then
e.g. for proving the callbyvalue termination of from Example 14(ii), we had
to verify in addition, that the interpretation of is different from for each
.
Note that callbyname termination requires to consider procedure calls of form
where the actual parameters are any expressions, whereas callby
value termination considers only values as actual parameters. This is because a
successful eager evaluationof a procedurecall entails a successful eager
CRITERIA FOR TERMINATION
evaluation of each actual parameter , hence it is enough to consider only values as
actual parameters. However, since a successful lazy evaluation of a procedure call
does not entail a successful lazy evaluation of each actual parameter in the call, the
restriction to value parameters would render the callbyname termination criterion
unsound:
Example 18
The functional procedure deﬁned as
function
if then
else
ﬁ
does not terminate callbyname, because e.g. . Let
deﬁned by
Then satisﬁes and we consider procedure calls with
. We ﬁnd for some whenever the evaluation of
leads to a recursivecall, where ,
and are the only recursive calls necessitated by the evaluation of
. Hence ( )
and .
Let iff and either , or
and .If , then and , hence
.If , then ,
hence . Finally
. Hence requirement 8(i) of callbyname termination is satisﬁed
for each recursive call which is necessitated by a procedure call having only value
arguments, although does not terminate.
6. STRONG TERMINATION
Proving the termination of a functional procedure generally requires the invention of
anappropriatepartialcorrectnessstatementabout andaproofofthisstatementforthe
veriﬁcation of the callbyvaluerequirement 12(i), cf. Example 14. So generally some
knowledge about the semantics of a functional procedure is inevitable for proving its
termination, and this complicates the termination proof. However, for some functional
proceduresterminationcanbeprovedwithoutreasoning aboutaprocedure’ssemantics.
We say that such functional procedures terminate strongly:
CHRISTOPH WALTHER
Deﬁnition 19 (Strong Termination)
A functional procedure terminates “strongly” iff some wellfounded relation
exists, such that
(i) for all with and for all
with and COND
holds for all functions .
Ifrequirement19(i)holdsfor all functions, then itholdsin particular for some func
tionsatisfying , and since requirements 12(i)and 19(i) coincide, strong termination
entails callbyvalue termination:
Corollary 20
If terminates strongly, then terminates callbyvalue.
Example 21
(i) The functional procedure deﬁned as
function
if then
else if then
else if then
else
ﬁ
ﬁ
ﬁ
terminates strongly: For a procedure call , the recursive calls
and have to be considered. If ,
then as well as . Hence requirement 19(i) is satisﬁed for
both recursive calls, and terminates strongly.
(ii) The functional procedure for Ackermann’s function, deﬁned as
function
if then
else if then
else
ﬁ
ﬁ
terminates strongly: Let the lexicographic order imposed by on .
We have to consider three recursive calls, viz. , and
, for a procedure call :
CRITERIA FOR TERMINATION
If ,then and if ,
then, as well as . Hence requirement
19(i) is satisﬁed for each recursive call, and terminates strongly.
Sincestrongterminationrequiresnoreasoningaboutthesemanticsofthefunctional
procedure under consideration, the results in nonrecursive cases and the contexts,in
which recursive calls are embedded, do not inﬂuence the termination behaviourof the
procedure. Hence any functional procedure strongly terminates “by construction”,
if is obtained from a strongly terminating functional procedure only by a mod
iﬁcation of the contexts of recursive calls and a replacement of result terms, which
do not introduce new recursive calls. Consequently, strong termination for an inﬁnite
class of functional procedures is proved, if strong termination is veriﬁed for only one
member of this class.
Example 22
Thefunctionalprocedure fromSection1terminatesstrongly,asitiseasilyveriﬁed
using iff . Hence the functional procedures
deﬁned as
function
if then
else if then
else
ﬁ
ﬁ
and deﬁned as
function
if then
else if then
else
ﬁ
ﬁ
must terminate strongly, as both procedures are obtained from only by modi
ﬁcation of the contexts of recursive calls and replacements of result terms, without
introduction of new recursive calls.
However, nonstrongly terminating functional procedures are sensitive for such
modiﬁcations, since this changes the semantics and consequently a non terminating
procedure may result.
CHRISTOPH WALTHER
Example 23
Let and functional procedures deﬁned by
function
if then
else
ﬁ
andfunction
if then
else
ﬁ
Both procedures do not terminate callbyvalue, as e.g. 
 . However, the functional procedure from Example 14(ii)
terminatescallbyvalue. resultsfrom by replacing in the nonrecursive
case of by , and results from by embedding the recursive call of
in the context .
7. NORMALRECURSIVE AND TAILRECURSIVE
PROCEDURES
Since strong termination demands requirement19(i) to hold for each function, it must
hold in particular also for functions not satisfying . Consequently strong termination
may fail for some callbyvalue terminating procedures:
Example 24
(i) The functional procedure from Example 14(i)does not terminatestrongly:
Let such that for all . Then
must hold, if , hence
must hold in particular. Since this is impossible for any
wellfounded relation , does not terminate strongly.
(ii) The functional procedure from Example 14(ii) does not terminate
strongly: Let such that for all . Then
( )musthold, if , hence
mustholdinparticular. Sincethisisimpossibleforanywellfounded relation ,
does not terminate strongly.
Note that the function in Example 24 does not satisfy the functional procedures
under consideration, hence callbyvalue termination is not spoiled upon the existence
of these functions, cf. Example 14.
Since strong termination is not necessary for callbyvalue termination but ob
viously is easier to verify, it seems worthwhile to recognize functional procedures
CRITERIA FOR TERMINATION
for which strong termination coincides with callbyvalue termination. We therefore
deﬁne the class of socalled normalrecursive functional procedures, i.e. procedures
which neither possess nested recursions nor have recursive calls in
the conditions of an ifstatement:
Deﬁnition 25 (NormalRecursive Functional Procedures)
A functional procedure is normalrecursive iff
does not occur in for all subterms and of .
Forinstance, the functional procedures for , , , , , and
are normalrecursive, whereas the functional procedures for , , , ,
, and are not. Now strong termination also is necessary for callby
value termination, if only normalrecursivefunctional procedures are considered:
Theorem 26
terminates strongly iff terminates callbyvalue,if is normalrecursive.
Proof: By Corollary 20.
Since is normalrecursive, neither COND( ) nor contain an 
term, hence the callbyvalue requirement 12(i) must hold for any function , and
therefore terminates strongly.
As a consequence of Theorem 26, we must fail in proving strong termination for
acallbyvalue terminating procedure , only if is not normalrecursive. In other
words, the notion of “normalrecursion” provides a trivial syntactic requirement to
decide whether a test for strong termination is enough, cf. Figure 4.
Note that “normalrecursion”is nota necessaryrequirementforstrong termination.
E.g. the functional procedures for and terminate strongly, cf. Example 21,
although both procedure are not normalrecursive.
Theorem 26 does not generalize to callbynametermination, i.e. there are normal
recursive callbyname terminating functional procedures, which do not terminate
strongly.
Example 27
The functional procedure deﬁned as
terminates callbyname and obviously is normalrecursive. However,
, i.e.
 , hence does not terminate callbyvalue. But then by
Corollary 20, does not terminate strongly either.
However, strong termination coincides with callbyname termination for a proper
subclass of the normalrecursivefunctional procedures: A normalrecursive procedure
istailrecursiveiffeachrecursivecall isneitherembeddedinanotherprocedure
CHRISTOPH WALTHER
call nor in a call of a base operationdifferent from . I.e., if the body of contains a
term of form , then .
Deﬁnition 28 (TailRecursive Functional Procedures)
Anormalrecursive procedure is tailrecursive iff
, or does not occur in for all subterms of .
E.g. the functional procedures for , , and are tailrecursive, whereas
the procedures for , , and are not. The functional procedures
for , , , and are not tailrecursive, because these procedures
are not normalrecursive.
Theclass of tailrecursiveproceduresiswellknown,inparticularbecausePROLOG
procedures and loops of imperative programs straightforwardly can be translated to
tailrecursive functional procedures and vice versa. For tailrecursive procedures,
strong termination also is necessary for (callbyname) termination:
Theorem 29
terminates strongly iff terminates (callbyname),if is tailrecursive.
Proof: By Corollary 20 and Theorem 13.
Let such that . Then “ for all subterms of
and for all such that and COND TRUE ” can be
proved by induction upon . Hence callbyname termination of entails callby
value termination of . But then terminates strongly by Theorem 26, because is
normalrecursive.
As a consequence of Theorem 29, for proving the termination of a loop in an
imperative program, no partial correctness statement about the semantics of the loop
is required.
Figure 4 summarizes the results by relating callbyname,callbyvalue and strong
termination w.r.t. normalrecursive and tailrecursive functional procedures.
8. CONCLUSION
Challenge problems for termination analysis, like the 91function, Ashcroft’s proce
dure for list reversal (Manna, 1974), Takeuchi’s and Collatz’ functions etc. provide
a valuable source for theoretical investigations (not only w.r.t. termination), but are
by no means typical examples of useful software. As procedures designed for practi
cal purposes usually are normalrecursive, a test for strong termination is enough in
practice. The only relevant exception from this argumentation are terminating non
normal recursive procedures with recursive calls in conditions (like ), which
e.g. “naturally” occur for operations on treelike structures. The functional procedure
CRITERIA FOR TERMINATION
Finner
Flouie
Fmod2
Fsmod2
Fack
Ftimes
Fmod
Fgcd
Fge
Fnull
Fquot
normalrecursivenon
Fplus
terminating
non
Fouter
Fhuey
Fdewey
strong
normalrecursive
Fnought
tailrecursive
terminating
callbyvalue
Figure 4 Termination of Functional Procedures
function
if then
else if then
else if then
else
ﬁ
ﬁ
ﬁ
is an example and the procedure value from (Boyer and Moore, 1979) is another one.
However, although not normalrecursive,these procedures also terminate strongly.
Therefore strong termination providesa solid formal base for an automated termi
nation analysis of procedures with eager semantics. The main challenge is to invent
a wellfounded relation such that the strong termination requirement 19(i) can be
CHRISTOPH WALTHER
proved, where an induction theorem prover, e.g. (Boyer and Moore, 1979; Walther,
1994a) can be used for this veriﬁcation.
For computing the “right” relation , an apriori ﬁxed relation does the job in
almost all realistic cases for procedures computing arithmetic functions or operating
on linear lists, viz. and comparing lists by their length respectively (Walther,
1994b; Giesl et al., 1998). However, sometimes this is not enough for procedures
working on more elaborate data structures, as e.g. graphs or treelike structures, and
(machine generated) polynomial orders have been proved successful for termination
analysis in this domain (Giesl, 1995;Giesl et al., 1998).
These proposals are developed further for the termination analysis of procedures
alsooperatingonnonfreedatastructures,ase.g. sets(Sengler,1996;Sengler,1997).
Anotherinterestingdevelopment,whichisinparticularusefulforloopprograms,isthe
termination analysis for functional programs in which not all procedures terminate:
Often the procedures of a program can be separated into interface procedures and
auxiliaryprocedures, where the latter cannot be called fromoutside. In such a scenario
it is enough that only the interface procedures terminate, whereas termination for the
auxiliary procedures must be guaranteed for certain inputs only, viz. the inputs
provided by the calls of the auxiliary procedures in the program, cf. (Brauburger,
1997; Giesl et al., 1998; Brauburger, 1999).
One key to success for automated termination proofs in languages with eager
semantics is the fact that requirement 19(i) of strong termination can be encoded by
a predicate logic formula, thus getting rid of the operational nature of termination.
However, for lazy languages the trivial computation of COND must be replaced by
some deductive concept modelling the necessary subevaluations given by . Hence
proofs for callbyname termination must mirror the evaluation of expression to some
extent, and this constitutes an increased difﬁculty of automated termination analysis
for lazy languages as compared to the eager case, cf. (Panitz and SchmidtSchauß,
1997; Panitz, 1997).
ACKNOWLEDGMENTS
I am grateful to M. Bormann, J. Brauburger, J. Giesl and D. McAllester for valuable comments
on a draft of this paper.
Department of Computer Science
Darmstadt University of Technology
64283 Darmstadt, Germany
NOTES
1. Of course, these proof procedures must be incomplete as the set of all total recursive functions is
not semidecidable.
2. All results presented subsequently straightforwardly carry over to more elaborate data structures, as
lists or trees.
CRITERIA FOR TERMINATION
3. Note that values are expressions too, since .
4. Since we are interested in the termination of algorithms only, we restrict lazy evaluation to procedure
calls and do not consider inﬁnite data structures, which would be obtained by e.g. dropping the side
conditions of rules 3 and 6.
5. is the transitive closure of and is the reﬂexive closure of .
6. A relation is wellfounded and ( , )isawellfounded set iff there is no inﬁnite
sequence of elements from .
7. By Theorem 2(ii) no value can be evaluated further, hence for all values
8. Monotonicity of a function is deﬁned w.r.t. the “moredeﬁned
orequal”relation on the cartesian product , where
iff either or for all . is monotonic iff
entails . We let [ ] denote the set of all monotonic
functions , see e.g. (Manna, 1974) for more details.
9. “ ( )” is an abbreviation for “ ”, where and
.
10. The symbol denotes equality of ﬁrstorder predicate logic.
11. denotes the “usual” greaterrelation on natural numbers, e.g.
.
12. satisﬁes iff is a ﬁxpoint of the functional associated with and since is the least ﬁxpoint
of this functional, must hold.
13. Guessing the semantics of a procedure seems to be the only way for proving termination in “hard”
cases, as e.g. for Takeuchi’s function, cf. (Moore, 1979; Knuth, 1991) and for Ashcroft’s function
(Manna, 1974). Also the termination proofs for the 91function were performed in this way (Manna, 1974;
Dershowitz and Manna, 1979; Knuth, 1991), except a solution presented in (Feferman, 1991). Recently
(Giesl, 1997) presented a proof based on a weaker (machine generated) partial correctness statement.
14. is the truncated division by , e.g. and .
15. abbreviates , which entails and
.
16. Generally, entails for all and all , but the evaluations may
differ in the intermediate steps as does not entail for certain .
17. By Theorem 16(ii), is strongly conﬂuent, hence is conﬂuent (Newman, 1942), and the
statement follows by 16(i).
18. The beneﬁts of using a relation for callbyvalue termination, i.e. the use of partial
instead of total correctness statements, were observed by J. Giesl, who proved a theorem corresponding
to the “if”part of Theorem 17 (Giesl, 1997). Our notion of callbyname termination was inspired by
this observation. However, due to the nature of lazy evaluation, the proof of Theorem 9 requires a more
complicated argumentation, cf. (Walther, 1998).
19. Since each functional associated with a functional procedure has one ﬁxpoint at least, cf. (Manna,
1974), at least one function satisfying exists.
20. By a moderate restriction of this approach, (McAllester and Arkoudas, 1996) even propose a pro
gramming discipline (comparable to a more “liberal” form of primitive recursion), in which only terminating
procedures can be deﬁned.
21. Freely and nonfreely generated data structures differ in the notion of equality, which isthe equality
on values in the former and a congruence relation on values in the latter case.
REFERENCES
Avenhaus, J. (1995). Reduktionssysteme. Springer.
Baader, F. and Nipkow, T. (1998). Term Rewriting and All That. Cambridge University Press.
Boyer, R. and Moore, J. S. (1979). A Computational Logic. Academic Press, Boston.
CHRISTOPH WALTHER
Brauburger, J.(1997). Automatic Termination Analysis for Partial Functions using Polynomial Orderings.
In Proceedings of the 4th International Static Analysis Symposium (SAS ’97), Paris, France, LNCS
1302, pages 330–344. Springer.
Brauburger, J. (1999). Automatic Termination Analysis for Functional and Imperative Programs. Doctoral
Dissertation TU Darmstadt, Inﬁx, St. Augustin, Germany.
Dershowitz, N. and Manna, Z. (1979).Proving termination with multiset orderings. CACM, 22(8):465–476.
Feferman, S. (1991). Proofs of termination and the "91" function. In Lifschitz, V., editor, Artiﬁcial Intelli
gence and Mathematical Theory of Computation, pages 47–63. Academic Press, Boston.
Gallier, J. H. (1986). Logic for Computer Science: Foundationsof Automatic TheoremProving. Harper and
Row, New York.
Gardner, M. (1983). Wheels, Lifes and other Mathematical Amusements. W. H. Freeman and Company,
New York.
Giesl,J.(1995).Automatisierung vonTerminierungsbeweisenf¨
urrekursivdeﬁnierteAlgorithmen,volume 96
of DISKI. Doctoral Dissertation TU Darmstadt, Inﬁx, St. Augustin, Germany.
Giesl, J. (1997). Termination of Nested and Mutually Recursive Algorithms. Journal of Automated Reason
ing, 19:1–29.
Giesl, J., Walther, C., and Brauburger, J. (1998). Termination Analysis for Functional Programs. In Bibel,
W.and Schmitt, P., editors, Automated Deduction — A Basis for Applications, volume 3, pages 135–164.
Kluwer Academic Publishers.
Knuth, D. (1991). Textbook examples of recursion. In Lifschitz, V., editor, Artiﬁcial Intelligence and
Mathematical Theory of Computation, pages 207–229. Academic Press, Boston.
Manna, Z. (1974). Mathematical Theory of Computation. McGrawHill.
McAllester and Arkoudas (1996). Walther Recursion. In Proceedings of the 13th International Conference
on Automated Deduction (CADE13), New Brunswick, USA, LNAI 1104, pages 643–657. Springer.
Moore, J. S. (1979). A Mechanical Proof of the Termination of Takeuchi’s Function. Information Processing
Letters, pages 176–181.
Newman, M. A. H. (1942). On theories with a combinatorical deﬁnition of ‘equivalence‘. Annals of Math
ematics, 43(2):223–243.
Panitz, S. (1997). Generierung statischer Programminformation zur Kompilierung verz
¨
ogert ausgewerteter
funktionaler Programmiersprachen. Doctoral Dissertation, Johann WolfgangGoetheUniversit
¨
at, Frank
furt am Main, Germany.
Panitz, S. and SchmidtSchauß, M. (1997). TEA: Automatically Proving Termination of Programs in a
NonStrict HigherOrder Functional Language. In Proceedings of the 4th International Static Analysis
Symposium (SAS ’97), Paris, France, LNCS 1302, pages 345–360. Springer.
Sengler, C. (1996). Termination of Algorithms over Nonfreely Generated Data Types. In Proceedings of
the 13th International Conference on Automated Deduction (CADE13), New Brunswick, USA,LNAI
1104, pages 121–136. Springer.
Sengler, C. (1997). Induction on NonFreely Generated Data Types, volume 160 of DISKI. Doctoral
Dissertation, Inﬁx, St. Augustin, Germany.
Walther, C.(1994a).MathematicalInduction.In Gabbay,D.,Hogger, C.,andRobinson,J.,editors, Handbook
of Logic in Artiﬁcial Intelligence and Logic Programming, volume 2. Oxford University Press.
Walther, C. (1994b). On proving the Termination of Algorithms by Machine. Artiﬁcial Intelligence,
71(1):101–157.
Walther, C. (1998). Recursion, Induction, Verﬁcation. Course Notes, TU Darmstadt.