2019-1-14 0

Halting According to aPToP

Eric C.R. Hehner

Department of Computer Science, University of Toronto

[email protected]

Introduction

In 1976, [0] suggested that computer programs could directly express their semantics, without
the need for a semantic function. The suggestion was made at the end of the paper, and not acted
upon in the paper. (Due to referee request, it was removed from the published version [1] of the
paper.) In 1981, [2] did act upon that suggestion (and also in the published version [3]), and it
became the basis for what was then called “Predicative Programming” [4][5]. More recently, the
same basis was used in the 1993 book a Practical Theory of Programming [6], and in the current
free online edition. We are using the initials of that book (aPToP) to designate this kind of
speci cation and program semantics. The same basis was used in the 1994 paper “the Temporal
Logic of Actions” [11], and in the 1998 book Unifying Theories of Programming [9].

We specify computation (computer behavior) using a binary (boolean) expression whose

nonlocal (free) variables represent whatever is of interest about the computation. In this paper,
the initial value x and nal value xʹ of a single natural variable, and the initial (start) time t
and nal (end) time tʹ of the computation are of interest. If the computation is unending, the
nal time is ∞ .

A program is a speci cation that has been implemented so that a computer can execute it. For
example, x:= x+2 is an assignment program (statement). If its execution takes time 1 , then
x:= x+2 = xʹ=x+2 ∧ tʹ=t+1

A speci cation s is called “implementable” if, for all initial states and times, there are nal
states and times to satisfy the speci cation, with nondecreasing time.
∀x, t· ∃xʹ, tʹ· s ∧ tʹ≥t
Let s be a speci cation and let p be a program. Then
∀x, t, xʹ, tʹ· s ⇐ p
says “ s is implied by p ”, “ s is re ned by p ”, “ s is implemented by p ”. It means that
execution of program p will satisfy speci cation s . If you implement an implementable
speci cation, then the speci cation becomes a program. Recursion is allowed. For example,
xʹ=0 ∧ tʹ=t+x ⇐ if x=0 then ok else x:= x–1. t:= t+1. xʹ=0 ∧ tʹ=t+x
The speci cation xʹ=0 ∧ tʹ=t+x is being implemented. Program ok is de ned as
(0) ok = xʹ=x ∧ tʹ=t
which directs a computer to do nothing (the “empty” program). The assignment t:= t+1 is not
an instruction to a computer; it is just accounting for the passage of time each loop iteration.
The loop is formed by the recursive use of the speci cation xʹ=0 ∧ tʹ=t+x ; re nement of the
speci cation xʹ=0 ∧ tʹ=t+x by a program makes xʹ=0 ∧ tʹ=t+x a program, so it can be used in
programs (even in the program re ning it). (Proof of the re nement is easy, and is omitted.)
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
f
fi
fi
 1 Eric Hehner 2019-1-14

The above speci cations and programs are “imperative”, meaning they describe a change in
state. We also need “functional” speci cations and programs. Any expression of a mathematical
function can serve as a functional speci cation. A functional program is a functional
speci cation that has been implemented so that a computer can execute it.

Halting Proof

There are various ways one may attempt to formalize the statement that execution of a program
terminates. Here is one: Let p be an imperative program; it is a binary expression in nonlocal
variables x , t , xʹ , and tʹ . Execution of p , starting in state x at time t , terminates if and
only if
(1) ∀xʹ, tʹ· p ∧ t<∞ ⇒ tʹ<∞
If execution of p starts at a nite time, it will end at a nite time. Expression (1) is the
mathematical halting function. It has nonlocal variables p (program), x (start state), and t
(start time). Let's call it halt , and turn its nonlocal variables into explicit parameters.
(2) halt p x t = ∀xʹ, tʹ· p ∧ t<∞ ⇒ tʹ<∞
halt p x t is ⊤ (binary “true”) if execution of p , starting in state x at time t , terminates, and
⊥ (binary “false”) otherwise.

Technical point: For programs to be parameters, they must be encoded as data. Turing
encoded them as numbers [13]. He called the decoder that turns numbers into programs
the Universal Machine. The modern practice is to encode programs as text (character
string); that is how programs are passed to compilers. The decoder that turns text into
program is called an interpreter. For example,
“x:= 0” = x:= 0
where is the interpreter. A text encoding of a program is so transparent that it is easy
to forget the difference between a program and its encoding as text. In the aPToP world,
a program is a speci cation, and the type of an imperative speci cation is binary: it
evaluates to ⊤ when a computation satis es it, and to ⊥ when a computation does not
satisfy it. But in halt p x t , we are not passing a binary value p to halt ; we are passing
text. Thus we are abusing notation, relying on the context to make it clear, rather than
cluttering our expressions with quotation marks and uses of .

Assume (in order to show a contradiction) that functional speci cation halt has been
implemented, and is therefore a functional program. We now create an imperative program, let's
call it twist , de ned as
(3) twist = if halt twist x t then loop else ok
where loop is de ned as
(4) loop = tʹ=∞
and easily implemented as
loop ⇐ t:= t+1. loop

Technical point: We assume there is a dictionary of de nitions, including (0), (2), (3),
and (4), that is accessible to halt , so that halt can look up ok , halt , twist , and loop
in the dictionary, and retrieve their texts for analysis.
fi
fi
fi
fi
fi
fi
fi
fi
fi
f
fi
fi
fi
fi
 2019-1-14 Halting According to aPToP 2

For any values of x and t , halt twist x t is either ⊤ or ⊥ . Suppose halt twist 0 0 = ⊤ . We
calculate:

⊤ supposition
= halt twist 0 0 (2)
= ∀xʹ, tʹ· twist ∧ 0<∞ ⇒ tʹ<∞ identity
= ∀xʹ, tʹ· twist ⇒ tʹ<∞ (3)
= ∀xʹ, tʹ· if halt twist 0 0 then loop else ok ⇒ tʹ<∞ supposition
= ∀xʹ, tʹ· if ⊤ then loop else ok ⇒ tʹ<∞ simplify if
= ∀xʹ, tʹ· loop ⇒ tʹ<∞ (4)
= ∀xʹ, tʹ· tʹ=∞ ⇒ tʹ<∞ portation
= ∀xʹ, tʹ· ⊥ identity
= ⊥

Now suppose halt twist 0 0 = ⊥ . We calculate:

⊥ supposition
= halt twist 0 0 (2)
= ∀xʹ, tʹ· twist ∧ 0<∞ ⇒ tʹ<∞ identity
= ∀xʹ, tʹ· twist ⇒ tʹ<∞ (3)
= ∀xʹ, tʹ· if halt twist 0 0 then loop else ok ⇒ tʹ<∞ supposition
= ∀xʹ, tʹ· if ⊥ then loop else ok ⇒ tʹ<∞ simplify if
= ∀xʹ, tʹ· ok ⇒ tʹ<∞ (0)
= ∀xʹ, tʹ· xʹ=0 ∧ tʹ=0 ⇒ tʹ<∞ specialization, identity
= ⊤

We have a contradiction. Therefore the assumption that there is a program to implement the
halting speci cation was wrong. This is the aPToP proof of the classic result by Turing [13].

Speci cation Version

In the proof of the previous section, we consider that there is a xed set of programs for halt to
apply to. If this set includes halt and twist , we have a contradiction.

The aPToP (and UTP [9] and TLA [11]) view of programs is different. aPToP was designed to
aid programmers in writing programs, and it takes their view. If you write a program, there is
now one more program than there was before you wrote it. Any implementable speci cation
becomes a program when it is re ned by a program. To be compatible with this view, we now
generalize functional speci cation halt to apply to all imperative speci cations.
(5) halt s x t = ∀xʹ, tʹ· s ∧ t<∞ ⇒ tʹ<∞ x
where s is any implementable speci cation. De nition (5) is identical to de nition (2), except
that in (2) halt applied only to programs, and in (5) halt applies to all speci cations (including
programs). halt s x t is ⊤ if s speci es a computation that, starting in state x at time t ,
terminates, and ⊥ otherwise.
fi
fi
fi
fi
fi
f
f
fi
f
f
fi
fi
fi
fi
fi
fi
 3 Eric Hehner 2019-1-14

If we assume that this generalized halt speci cation is implemented, then both halt and twist
are programs, and the exact same calculations (previous section) arrive at the same contradiction.
If halt is not implemented, then both halt and twist are not programs, but they are nonetheless
speci cations. And the exact same calculations (previous section, except that hint (2) becomes
hint (5)) arrive at the same contradiction. We arrive at this contradiction without having assumed
that there is a program to implement the halting speci cation. So we have no assumption to
blame for the contradiction. The conclusion is that de nitions (5) and (3) ( halt and twist )
together are inconsistent. That is the conclusion whether or not halt and twist are programs.
The inconsistency neither appears nor disappears by changing the domain of halt from
programs to all speci cations. For a similar conclusion, see [12]. For a contrary conclusion, see
[10].

Discussion

What Turing proved, and what many textbooks prove, and what we proved in this paper in aPToP
style, is

A. The de nition of halt as a program applying to program twist is inconsistent.

From that, we might conclude

B. The de nition of halt as a program applying to all programs is inconsistent.

If a consistent speci cation cannot be implemented in a Turing-Machine-Equivalent (TME)

programming language, we say it is “undecidable”. The speci cation must be consistent so that
it does specify something, and it must be something a TME programming language is not
expressive enough to implement. An inconsistent speci cation cannot be implemented in any
consistent language, no matter how powerful or expressive, but that doesn't merit calling it
“undecidable”. If it did, we could just use ⊥ as an example of an undecidable speci cation. To
say that halting is “undecidable”, we also need

C. The de nition of halt as an unimplemented speci cation applying to all programs is

consistent.

C is not proven, but it is commonly believed for the weak reason that no inconsistency is
apparent. B and C are necessary to call halting “undecidable”, but they are not suf cient. The
problem lies in the words “all programs” in B and C.

The aPToP approach begins with speci cations. We prove

D. The de nition of halt as a speci cation applying to all speci cations is inconsistent.

by exactly the same proof that we used to prove A, except that halt and twist are speci cations
(they may or may not be programs), and halt applies to all speci cations (including but not
limited to programs).
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 2019-1-14 Halting According to aPToP 4

In the aPToP view, programs are a growing subset of speci cations; when an implementable
speci cation is re ned by a program, that speci cation becomes a program. So we might limit
our attention to implementable speci cations, which are the potential programs. In de nition (3),
if halt twist x t = ⊤ , then twist = loop , so twist is implementable. And if halt twist x t = ⊥ ,
then twist = ok , so again twist is implementable. Therefore twist is classically
implementable. But since we cannot determine whether halt twist x t is ⊤ or ⊥ , twist is not
constructively implementable. Classically, we can conclude

E. The de nition of halt as an unimplemented speci cation applying to implementable

speci cations is inconsistent.

Contrast C with E: changing “programs” to “implementable speci cations” changes “consistent”

to “inconsistent”.

If we reduce the domain of halt to just the two programs loop and ok , halt is easily
implemented. So

F. The de nition of halt as a program applying to the programs loop and ok is consistent.

To talk about “all programs”, we need to have a syntactically de ned programming language,
and then we can talk about all programs in that language. We shall say “L-program” for a
program written in TME programming language L. Conclusion B becomes

G. The de nition of halt as an L-program applying to all L-programs is inconsistent.

That's because, if halt is an L-program, then there is an L-program just like twist . So we dare
to suggest

H. The de nition of halt as an L-program is consistent if we restrict its domain to those L-

programs that do not refer to halt , neither directly nor indirectly through other L-programs.

This is not the largest class for which a halt program exists; there are L-programs that refer to
halt in a benign fashion, and could be included without inconsistency. Consider
(6) straight = if halt straight x t then ok else loop
For any values of x and t , halt straight x t is either ⊤ or ⊥ . Suppose halt straight 0 0 = ⊤ .
We calculate:

⊤ supposition
= halt straight 0 0 (2)
= ∀xʹ, tʹ· straight ∧ 0<∞ ⇒ tʹ<∞ identity
= ∀xʹ, tʹ· straight ⇒ tʹ<∞ (3)
= ∀xʹ, tʹ· if halt straight 0 0 then ok else loop ⇒ tʹ<∞ supposition
= ∀xʹ, tʹ· if ⊤ then ok else loop ⇒ tʹ<∞ simplify if
= ∀xʹ, tʹ· ok ⇒ tʹ<∞ (0)
= ∀xʹ, tʹ· xʹ=0 ∧ tʹ=0 ⇒ tʹ<∞ specialization, identity
= ⊤
fi
fi
fi
fi
fi
fi
fi
fi
f
fi
f
f
fi
fi
fi
fi
fi
 5 Eric Hehner 2019-1-14

Now suppose halt straight 0 0 = ⊥ . We calculate:

⊥ supposition
= halt straight 0 0 (2)
= ∀xʹ, tʹ· straight ∧ 0<∞ ⇒ tʹ<∞ identity
= ∀xʹ, tʹ· straight ⇒ tʹ<∞ (3)
= ∀xʹ, tʹ· if halt straight 0 0 then ok else loop ⇒ tʹ<∞ supposition
= ∀xʹ, tʹ· if ⊥ then ok else loop ⇒ tʹ<∞ simplify if
= ∀xʹ, tʹ· loop ⇒ tʹ<∞ (0)
= ∀xʹ, tʹ· tʹ=∞ ⇒ tʹ<∞
= ∀xʹ, tʹ· ⊥ identity
= ⊥

We can suppose halt straight 0 0 is ⊤ or ⊥ without any inconsistency. Therefore a halt

program, when applied to program straight , can return either ⊤ or ⊥ .

In [7] and [8] the suggestion is made to de ne halt to work on all L-programs, and to write an
implementation of halt in TME language M, where L-programs cannot call M-programs. This
disallows the inconsistency proof, while at the same time de ning and implementing halt to
apply to all programs in a TME language. If we can do that, then we cannot call halting
“undecidable”.

The obvious objection to this suggestion is that if we could program halt in language M to
apply to all L-programs, we could translate it into language L; but there is no L-program to
implement halt for all L-programs, so there cannot be an M-program to do so either. The
objection is wrong: even though halt written in language M does compute halting for all L-
programs, its translation to an L-program does not compute halting for all L-programs. This
surprising result is the subject of [8].

Conclusion

For Turing, and for most of the programming world today, even for most of the formal methods
community, programs and speci cations are different things. They have separate languages in
which they are expressed. Programs are instructions to a computer, not mathematical
expressions. Formal speci cations are mathematical expressions, not instructions to a computer.
Speci cations are used to reason about programs.

To the majority of people, the Halting Problem is about programs, not about speci cations. The
computability assumption is essential; we have to assume the existence of a program to compute
halting so that we can reason about it. An inconsistency is created by the assumption that such a
program exists. The reasoning that there is an inconsistency uses speci cations, but, to the
majority of people, the speci cations are talking about programs.

In the aPToP world [6], programs are a growing subset of speci cations. We do not specify
programs; we specify computation, or computer behavior. Programs are those speci cations
that have been implemented so that they can be executed by a computer. If we prove something
fi
fi
fi
fi
f
fi
f
fi
fi
fi
fi
fi
 2019-1-14 Halting According to aPToP 6

about all speci cations, that includes all programs. If we nd an inconsistency in a collection of
speci cations, that nding is unaffected by an assumption that one or more of the speci cations
are programs.

Maybe a revision of the Halting Problem will have to wait (possibly forever) until the aPToP
view of programming is accepted.

References

[0] E.C.R.Hehner: “do considered od: a Contribution to the Programming Calculus”,

CSRG-75, U. of Toronto, 1976 November
[1] E.C.R.Hehner: “do considered od: a Contribution to the Programming Calculus”,
Acta Informatica, v.11 p.287-304, 1979
[2] E.C.R.Hehner, C.A.R.Hoare: “Another Look at Communicating Processes”,
CSRG-134, U. of Toronto, 1981 September
[3] E.C.R.Hehner, C.A.R.Hoare: “a More Complete Model of Communicating
Processes”, Theoretical Computer Science, v.26 p.105-120, 1983 September
[4] E.C.R.Hehner: “Predicative Programming, Part I”, Communications of the ACM,
v.27 n.2 p.134-143, 1984 February
[5] E.C.R.Hehner: “Predicative Programming, Part II”, Communications of the ACM,
v.27 n.2 p.144-151, 1984 February
[6] E.C.R.Hehner: a Practical Theory of Programming, Springer, 1993;
current edition hehner.ca/aPToP
[7] E.C.R.Hehner: “How to Compute Halting”, 2014 January 2
[8] E.C.R.Hehner: “Objective and Subjective Speci cations”, 2017 July 10,
WST Workshop on Termination, Oxford, 2018 July 18
[9] C.A.R.Hoare, J.He: Unifying Theories of Programming, Prentice-Hall, 1998
[10] C.Huizing, R.Kuiper, T.Verhoeff: “No Holes in Halting – Programs versus Speci cations”,
International Symposium on Unifying Theories of Programming, Springer LNCS v.6445
p.226-233, Shanghai, 2010 November 15-16
[11] L.Lamport: “the Temporal Logic of Actions”, ACM Transactions on Programming
Languages and Systems, v.16 n.3 p.872-923, 1994 May
[12] W.Stoddart: “the Halting Paradox”, FACS FACTS: the Newsletter of the Formal
Aspects of Computing Science Specialist Group, 2018 January
[13] A.M.Turing: “on Computable Numbers with an Application to the
Entscheidungsproblem”, Proceedings of the London Mathematical Society
s.2 v.42 p.230-265, 1936; correction s.2 v.43 p.544-546, 1937

other papers on halting

Appendix

The aPToP speci cation of termination is tʹ ≤ t + f x where f is a nonnegative and nite

function. It may seem that tʹ<∞ expresses termination more simply. But tʹ<∞ is an
unimplementable speci cation. That's because programs, and more generally speci cations, can
be composed sequentially. If the rst program in a sequential composition is an in nite loop,
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
 7 Eric Hehner 2019-1-14

then its execution ends at time ∞ (in other words, it never ends), and so execution of the second
program in the sequential composition starts at time ∞ (in other words, it never starts). Since
any program can be placed following an in nite loop, a speci cation cannot promise that
execution will end before time ∞ (at a nite time). But it can promise that execution will take a
nite amount of time.

An implementable candidate to express termination is t<∞ ⇒ tʹ<∞ ; if the computation starts at

a nite time, then it ends at a nite time. But, surprisingly, this speci cation can be implemented
by an in nite loop.
t<∞ ⇒ tʹ<∞ ⇐ t:= t+1. t<∞ ⇒ tʹ<∞
In order for a user of this program to complain that its execution violates the speci cation, the
user must observe computer behavior contrary to the speci cation. The user must observe that
the computation starts at a nite time (easy), and ends at time in nity (it never ends). All
observations are made at nite times; the user can never complain that the computation has
taken forever. So this candidate fails to express termination.

The speci cation tʹ ≤ t + f x for any given nonnegative nite function f does express
termination, and furthermore, gives a time bound for termination. If execution takes longer than
f x , the user can complain. The speci cation tʹ=∞ does express nontermination; if execution
ends at a nite time, the user can complain. For further details, see [6 p.50-51].
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi
fi