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 verifica-
tion. Termination proofs can be quite complicated, e.g. proving the termination of
McCarthy’s 91-function
function
if then
else
fi
or Takeuchi’s function
function
if then
else
fi
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
fi
fi
(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
fi
fi
fi
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 sufficient criteria and demonstrate their
success and failure by examples. We also define 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 finitely 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
defined 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 many-sorted 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 defined only by using base operations, by previously defined 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 defined
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 defined as
function
To ease readability, we use abbreviations like “ ” for “ ”, “ ” for
“ ”, “if then else fi” for “ ”, “ ” for “ ” and
“ ” for “ ”. We also use the standard mathematical notation for function
symbols if appropriate. E.g.
function
if then
else
fi
defines a functional procedure and
function
if then
else if then
else
fi
fi
CHRISTOPH WALTHER
defines a procedure in a more readable notation, and is a
functional program.
2. OPERATIONAL SEMANTICS AND TERMINATION
Having defined the syntax of the kind of functional programswe are concerned with,
we now provide a semantics for these programs. This is achieved by defining 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):
Definition 1 (Evaluation Calculus for M)
Let , , , , .
Then the evaluation calculus for the machine Mis given by the following inference
rules:
where is a substitution defined as
.
We call the evaluation relation of M, where holds iff some inference rule
exists, such that the application requirement is satisfied.
The terms in rule (11) are the actual parameters of the procedure
call . Here procedure calls are implemented by the parameter passing
discipline call-by-name (sometimes also called call-by-need), 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 well-founded 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 define 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 well-founded set. For instance,
may rise an infinite 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 non-value 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 infinite evaluations are impossible:
Definition 3 (Termination of Functional Programs)
A functional program terminates iff ( , ) is a well-founded set.
Since our development excludes mutual recursion, the termination of a functional
program can be expressed by a notion of termination forfunctional procedures:
Definition 4 (Termination of Functional Procedures)
Let be a functional program, such that terminates. Then the
functional procedure terminates iff terminates.
CHRISTOPH WALTHER
By this definition, 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 difficulty of provingthe termination
of functional programs.
3. DENOTATIONAL SEMANTICS OF FUNCTIONAL
PROGRAMS
Denotational semantics provide an alternative approachto the operational semantics
of functional programs defined by the interpreter . Since denotational semantics
uses semantical notions of first-order 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 undefinedness 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 defined by , and
. “respects” the values of M, i.e. , if
, and . For function symbols which are introduced by a
functional procedure , is defined as the least fixpoint of the functional obtained
from , see e.g. (Manna, 1974).
As usual, we write ( ) for the interpretation of an expression by
. In denotational semantics, non-termination of functional procedures is modelled
by the symbols for undefinedness, 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 defined
in such a way, that the interpretation ( )of corresponds to the result ofevaluating
by iff such an evaluation succeeds, and is interpreted as “undefined” otherwise.
CRITERIA FOR TERMINATION
4. CALL-BY-NAME TERMINATION
Let and let be a functional program,
such that terminates. Then does not terminate, if there is an infinite sequence S
of expressions , , , such that the evaluation of leads to the
evaluationof for all . On the contrary,ifeachcall of necessitates
onlyfinitely 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 infinite sequence of recursive calls like Sabove.
Thekeypointin the definition 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 non-value expression of a
functional program and some iff the evaluation of by necessitates
the evaluation of the subterm :
Definition 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 first 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 then-part of a conditional is only necessary, if the condition
evaluates to , cf. (ii), and the evaluation of the else-part 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 non-termination. 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 (non-instantiated) 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 only-if case is obvious, and the if-case 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
Definition 8 (call-by-name Termination)
A functional procedure terminates “call-by-name” iff some well-founded relation
and some function exists, such that
(i) for all with and for all
with and , and
(ii) satisfies , i.e. .
For each procedure call , call-by-name 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 well-founded relation than the interpreta-
tion ( ) of the argument list belongingto the initial procedure call . The
interpretation of the arguments is fixed 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 definition of , when proving (i). In other words, determines the
CHRISTOPH WALTHER
sequences Sof procedure calls , , , to be considered and guarantees
that these sequences are finite, 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 call-by-name.
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 finite. We choose
, i.e. is the function computed by , therefore , and
satisfies .Nowif and , then the evaluation of leads to the
evaluationof , hence , and terminatescall-by-name.
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 call-by-name,
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 defined as
function
if then
else
fi
terminatescall-by-name: Let suchthat satisfies . Then
(*) “ implies for all and for all ”, as it is
easily verified by Peano induction upon .
A procedure call necessitates the evaluation of the recursive calls (
) and . Let iff
and either or . We find for some
CRITERIA FOR TERMINATION
whenever the evaluation of leads to a recursive call. Hence ,
because satisfies , and therefore . So we obtain
.
If , then
. Otherwise , cf. (*), hence
, and require-
ment 8(i) is satisfied for the first recursive call. Since
, requirement 8(i) is satisfied also forthe other
recursive call. Since no other recursive calls are necessitated by the evaluation of
, terminates call-by-name.
(ii) The functional procedure
does not terminate call-by-name: Each procedure call necessitates
the evaluation of the recursive call and there is no well-founded relation
satisfying .
Example 10(i) illustrates the problemsto be solved if call-by-name termination of
a functional procedure has to be verified: First, one has to “guess” a well-founded
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 “ satisfies ” in Definition 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 well-founded relation of Definition 8 is defined on , so values can be
compared with the undefinedness symbol in particular. This looks odd at a first
glance, since termination entails the absence of undefinedness, cf. Theorem 5. By
Theorem 9, we can always find a well-founded relation defined on , such that
the requirements of call-by-name termination are satisfied 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 defined on . So we had to verify (**) “ for all
and all ” too.
Hence using a well-founded relation defined 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 difficult proof of Theorem9.
5. CALL-BY-VALUE TERMINATION
The criterion of Definition 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
well-founded relation and a partial correctness statement about carrying the
proof of 8(i), the main obstacle in applying call-by-name 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 Definition 8 by a weaker requirement, which however is easier to decide.
To this effect, we associate with each subterm of a term a quantifier-free
formulaCOND( , ), which must be satisfied whenever isevaluatedontheevaluation
of , i.e. whenever holds: Let be a subterm-tree 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 satisfied, 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,y-x)
=
=
...
zero(x)
...
zero(y)
gcd(x-y,y)ge(x,y) if(zero(x),y,gcd(x,y-x))
zero(y) false
if(ge(x,y),gcd(x-y,y),if(zero(x),y,gcd(x,y-x)))x
if(zero(y),x,if(ge(x,y),gcd(x-y,y),if(zero(x),y,gcd(x,y-x))))
y
Figure 3 Labelled subterm tree ( ) for the computation of ( , )
Definition 12 (call-by-value Termination)
A functional procedure terminates “call-by-value” iff some well-founded relation
and some function exists, such that
(i) for all with and for all
with and COND , and
(ii) satisfies , i.e. .
For each procedure call , call-by-valuetermination demands that the interpreta-
tion of the parameter list which belongs to an executable recursive
call has to be smaller w.r.t. some well-founded relation than the argument
list belonging to the initial procedure call .
Since entails COND ,call-by-value termination
entails (call-by-name) termination:
Theorem 13
If terminates call-by-value, then terminates (call-by-name).
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 call-by-value, and with
a contradiction is obtained.
Example 14
(i) The functional procedure defined as
function
if then
else if then
else if then
else
fi
fi
fi
terminates call-by-value: Let such that satisfies . Then
(*) “ implies or for all ”, as it is easily verified
by a two-step 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 satisfied for both recursive calls, terminates call-
by-value.
(ii) The functional procedure defined as
function
if then
else
fi
terminates call-by-value: Let such that satisfies . Then
(*) “ implies for all ”, as it is easily verified by Peano
inductionupon . Foraprocedurecall ,therecursivecalls
and have to be considered:
CRITERIA FOR TERMINATION
Let be the well-founded relation defined by iff and either
or .If , then .If
, then , and if , then
by (*), hence also in this case. Since
requirement 12(i) is satisfied for both recursive calls, terminates call-by-value.
Call-by-valuetermination is easier to verify than call-by-name termination, simply
because it has not to be determined whether an executable recursive call will be
executed in fact. As a consequence, however,call-by-value termination only provides
a sufficient termination requirement, as there are terminating functional procedures,
which do not terminate call-by-value:
Example 15
The (terminating) functional procedure from Example 10 does not terminate
call-by-value, since there is no well-founded relation such that for
some . In other words, does not terminate call-by-value, because the
body of contains a recursive call , which results in non-termination,
if executed. However, since is never executed, this recursive call does not
spoil the (call-by-name) termination of .
However, call-by-value termination equivalently characterizes the successful eval-
uation of each term, if procedure calls in a functional program are implemented by
the parameter passing discipline call-by-value(instead of the call-by-namediscipline).
The corresponding evaluation strategy is called eager evaluation and is obtained by
restricting all actual parameters in rule(11) ofthe evaluation calculus (cf. Definition 1)
to be values only, yielding
For procedure calls with non-value 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 confluence 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 definition is applied, actual
parameters are evaluated also if their values do not contribute to the result, and this
may cause non-termination in cases where lazy evaluationsucceeds.
Theorem 17
- for all iff terminates call-by-value 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
COND-formula for to TRUE. Then - for some ,
since - for all . Consequently and
COND , hence , because terminates by-value,
contradicting the -minimality of .
Hence - for all and since - for all
, - for all .
Like in the definition of call-by-name termination, the well-founded relation
used for call-by-value termination also is defined on , yielding the same benefits
as for call-by-name termination: If had been demanded instead, then
e.g. for proving the call-by-value termination of from Example 14(ii), we had
to verify in addition, that the interpretation of is different from for each
.
Note that call-by-name termination requires to consider procedure calls of form
where the actual parameters are any expressions, whereas call-by-
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 call-by-name termination criterion
unsound:
Example 18
The functional procedure defined as
function
if then
else
fi
does not terminate call-by-name, because e.g. . Let
defined by
Then satisfies and we consider procedure calls with
. We find 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 call-by-name termination is satisfied
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
verification of the call-by-valuerequirement 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
Definition 19 (Strong Termination)
A functional procedure terminates “strongly” iff some well-founded 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 call-by-value termination:
Corollary 20
If terminates strongly, then terminates call-by-value.
Example 21
(i) The functional procedure defined as
function
if then
else if then
else if then
else
fi
fi
fi
terminates strongly: For a procedure call , the recursive calls
and have to be considered. If ,
then as well as . Hence requirement 19(i) is satisfied for
both recursive calls, and terminates strongly.
(ii) The functional procedure for Ackermann’s function, defined as
function
if then
else if then
else
fi
fi
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 satisfied for each recursive call, and terminates strongly.
Sincestrongterminationrequiresnoreasoningaboutthesemanticsofthefunctional
procedure under consideration, the results in non-recursive cases and the contexts,in
which recursive calls are embedded, do not influence 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-
ification of the contexts of recursive calls and a replacement of result terms, which
do not introduce new recursive calls. Consequently, strong termination for an infinite
class of functional procedures is proved, if strong termination is verified for only one
member of this class.
Example 22
Thefunctionalprocedure fromSection1terminatesstrongly,asitiseasilyverified
using iff . Hence the functional procedures
defined as
function
if then
else if then
else
fi
fi
and defined as
function
if then
else if then
else
fi
fi
must terminate strongly, as both procedures are obtained from only by modi-
fication of the contexts of recursive calls and replacements of result terms, without
introduction of new recursive calls.
However, non-strongly terminating functional procedures are sensitive for such
modifications, since this changes the semantics and consequently a non terminating
procedure may result.
CHRISTOPH WALTHER
Example 23
Let and functional procedures defined by
function
if then
else
fi
andfunction
if then
else
fi
Both procedures do not terminate call-by-value, as e.g. -
- . However, the functional procedure from Example 14(ii)
terminatescall-by-value. resultsfrom by replacing in the non-recursive
case of by , and results from by embedding the recursive call of
in the context .
7. NORMAL-RECURSIVE AND TAIL-RECURSIVE
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 call-by-value 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
well-founded 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. Sincethisisimpossibleforanywell-founded relation ,
does not terminate strongly.
Note that the function in Example 24 does not satisfy the functional procedures
under consideration, hence call-by-value termination is not spoiled upon the existence
of these functions, cf. Example 14.
Since strong termination is not necessary for call-by-value termination but ob-
viously is easier to verify, it seems worthwhile to recognize functional procedures
CRITERIA FOR TERMINATION
for which strong termination coincides with call-by-value termination. We therefore
define the class of so-called normal-recursive functional procedures, i.e. procedures
which neither possess nested recursions nor have recursive calls in
the conditions of an if-statement:
Definition 25 (Normal-Recursive Functional Procedures)
A functional procedure is normal-recursive iff
does not occur in for all subterms and of .
Forinstance, the functional procedures for , , , , , and
are normal-recursive, whereas the functional procedures for , , , ,
, and are not. Now strong termination also is necessary for call-by-
value termination, if only normal-recursivefunctional procedures are considered:
Theorem 26
terminates strongly iff terminates call-by-value,if is normal-recursive.
Proof: By Corollary 20.
Since is normal-recursive, neither COND( ) nor contain an -
term, hence the call-by-value 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
acall-by-value terminating procedure , only if is not normal-recursive. In other
words, the notion of “normal-recursion” provides a trivial syntactic requirement to
decide whether a test for strong termination is enough, cf. Figure 4.
Note that “normal-recursion”is nota necessaryrequirementforstrong termination.
E.g. the functional procedures for and terminate strongly, cf. Example 21,
although both procedure are not normal-recursive.
Theorem 26 does not generalize to call-by-nametermination, i.e. there are normal-
recursive call-by-name terminating functional procedures, which do not terminate
strongly.
Example 27
The functional procedure defined as
terminates call-by-name and obviously is normal-recursive. However,
, i.e.
- , hence does not terminate call-by-value. But then by
Corollary 20, does not terminate strongly either.
However, strong termination coincides with call-by-name termination for a proper
subclass of the normal-recursivefunctional procedures: A normal-recursive procedure
istail-recursiveiffeachrecursivecall 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 .
Definition 28 (Tail-Recursive Functional Procedures)
Anormal-recursive procedure is tail-recursive iff
, or does not occur in for all subterms of .
E.g. the functional procedures for , , and are tail-recursive, whereas
the procedures for , , and are not. The functional procedures
for , , , and are not tail-recursive, because these procedures
are not normal-recursive.
Theclass of tail-recursiveproceduresiswell-known,inparticularbecausePROLOG
procedures and loops of imperative programs straightforwardly can be translated to
tail-recursive functional procedures and vice versa. For tail-recursive procedures,
strong termination also is necessary for (call-by-name) termination:
Theorem 29
terminates strongly iff terminates (call-by-name),if is tail-recursive.
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 call-by-name termination of entails call-by-
value termination of . But then terminates strongly by Theorem 26, because is
normal-recursive.
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 call-by-name,call-by-value and strong
termination w.r.t. normal-recursive and tail-recursive functional procedures.
8. CONCLUSION
Challenge problems for termination analysis, like the 91-function, 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 normal-recursive, 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 tree-like structures. The functional procedure
CRITERIA FOR TERMINATION
Finner
Flouie
Fmod2
Fsmod2
Fack
Ftimes
Fmod
Fgcd
Fge
Fnull
Fquot
normal-recursivenon
Fplus
terminating
non
Fouter
Fhuey
Fdewey
strong
normal-recursive
Fnought
tail-recursive
terminating
call-by-value
Figure 4 Termination of Functional Procedures
function
if then
else if then
else if then
else
fi
fi
fi
is an example and the procedure value from (Boyer and Moore, 1979) is another one.
However, although not normal-recursive,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 well-founded 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 verification.
For computing the “right” relation , an a-priori fixed 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 tree-like 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
alsooperatingonnon-freedatastructures,ase.g. sets(Sengler,1996;Sengler,1997).
Anotherinterestingdevelopment,whichisinparticularusefulforloop-programs,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 call-by-name termination must mirror the evaluation of expression to some
extent, and this constitutes an increased difficulty of automated termination analysis
for lazy languages as compared to the eager case, cf. (Panitz and Schmidt-Schauß,
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 semi-decidable.
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 infinite 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 reflexive closure of .
6. A relation is well-founded and ( , )isawell-founded set iff there is no infinite
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 defined w.r.t. the “more-defined-
or-equal”-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 first-order predicate logic.
11. denotes the “usual” greater-relation on natural numbers, e.g.
.
12. satisfies iff is a fixpoint of the functional associated with and since is the least fixpoint
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 91-function 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 confluent, hence is confluent (Newman, 1942), and the
statement follows by 16(i).
18. The benefits of using a relation for call-by-value 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 call-by-name 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 fixpoint 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 defined.
21. Freely and non-freely 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, Infix, 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, Artificial 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¨
urrekursivdefinierteAlgorithmen,volume 96
of DISKI. Doctoral Dissertation TU Darmstadt, Infix, 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, Artificial Intelligence and
Mathematical Theory of Computation, pages 207–229. Academic Press, Boston.
Manna, Z. (1974). Mathematical Theory of Computation. McGraw-Hill.
McAllester and Arkoudas (1996). Walther Recursion. In Proceedings of the 13th International Conference
on Automated Deduction (CADE-13), 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 definition 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 WolfgangGoethe-Universit
¨
at, Frank-
furt am Main, Germany.
Panitz, S. and Schmidt-Schauß, M. (1997). TEA: Automatically Proving Termination of Programs in a
Non-Strict Higher-Order 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 Non-freely Generated Data Types. In Proceedings of
the 13th International Conference on Automated Deduction (CADE-13), New Brunswick, USA,LNAI
1104, pages 121–136. Springer.
Sengler, C. (1997). Induction on Non-Freely Generated Data Types, volume 160 of DISKI. Doctoral
Dissertation, Infix, St. Augustin, Germany.
Walther, C.(1994a).MathematicalInduction.In Gabbay,D.,Hogger, C.,andRobinson,J.,editors, Handbook
of Logic in Artificial Intelligence and Logic Programming, volume 2. Oxford University Press.
Walther, C. (1994b). On proving the Termination of Algorithms by Machine. Artificial Intelligence,
71(1):101–157.
Walther, C. (1998). Recursion, Induction, Verfication. Course Notes, TU Darmstadt.
