26

"Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist"

Can I find a general algorithm to solve the halting problem for some possible program input pairs?

Can I find a programming language (or languages), where I for every kind of program in this language, it can decide if the program terminates or run forever?

Kaveh
  • 22,661
  • 4
  • 53
  • 113

6 Answers6

27

Can I find a general algorithm to solve the halting problem for some possible program input pairs?

Yes, sure. For example you could write an algorithm that returns "Yes, it terminates" for any program which contains neither loops nor recursion and "No, it does not terminate" for any program that contains a while(true) loop that will definitely be reached and doesn't contain a break statement, and "Dunno" for everything else.

Can I find a programming language (or languages), where I for every kind of program in this language, it can decide if the program terminates or run forever?

Not if that language is Turing-complete, no.

However there are non-Turing complete languages like for example Coq, Agda or Microsoft Dafny for which the Halting Problem is decidable (and in fact is decided by their respective type systems, making them total languages (i.e. a program that might not terminate will not compile)).

sepp2k
  • 1,750
  • 14
  • 23
3

I think all the answers here completely and utterly miss the point. The answer to the question is: assuming the program is intended to halt, then yes you had better be able to show it stops. If you cannot show it stops easily then the program should be considered very badly written and rejected by Quality Control as such.

Whether you can actually write a suitable machine algorithm depends on the input programming language and how ambitious you are. It is a reasonable design goal for a programming language to make it easily possible to prove termination.

If the language is C++ you probably can't write the tool, indeed it is unlikely you'd ever get the parser going, let alone prove termination. For a better structured language, you should at be able to generate a proof, or at least do so with certain assumptions: in the latter case the tool should output these assumptions. A similar approach would be to include termination assertions in the language and use them in complex situations where the tool would trust the assertions.

The bottom line is that no one seems to understand that proof a program halts is indeed possible because (good) programmers intending to write such halting programs always do so intentionally and with a mental picture of why they terminate and act correctly: such code is deliberately written so it is clear that they halt and are correct and if a reasonable algorithm cannot prove this, possibly with some hints, then the program should be rejected.

The point: programmers don't write arbitrary programs, so the thesis of the halting theorem isn't satisfied and the conclusion doesn't apply.

Yttrill
  • 167
  • 2
3

excellent and (prob unintentionally deep) question. there are indeed halting-detecting programs that can succeed on limited sets of inputs. its an active area of research. it has very strong ties to (automated) theorem proving areas.

however computer science does not appear to have an exact term for "programs" that "sometimes" succeed. the word "algorithm" is usually reserved for programs that always halt.

the concept seems to be distinctly different than probabilistic algorithms where CS theorists insist there be some known or computable probability on their succeeding.

there is a term semialgorithms that is used sometimes but its apparently a synonym for recursively enumerable or noncomputable.

so for purposes here, call them quasialgorithms. the concept is different than decidable vs undecidable.

one might say that one cannot compare quasialgorithms. but in fact there seems to be a natural hierarchy (a partial ordering) of these quasialgorithms. suppose a quasialgorithm $A$ can detect halting of some limited set of input programs say $X$. another one $B$ can detect halting of a set $Y$. if $X \subset Y$ ie $X$ is proper subset of $Y$ then $B$ is "more powerful" than $A$.

in CS this "quasi algorithm hierarchy" seems to be studied mostly only informally so far.

it shows up in busy beaver research[1] and the PCP problem[2]. in fact a DNA based computing attack on PCP can be seen as a quasialgorithm.[3] and its seen in other areas already noted such as theorem proving[4].

[1] New millenium attack on the busy beaver problem

[2] Tackling Posts correspondence problem by Zhao (v2?)

[3] Using DNA to solve the Bounded Post Correspondence Problem by Kari et al

[4] proving program termination by Cook et al, Comm. of the ACM

(so this is actually a very deep question that defn deserves to be on TCS.SE imho... maybe someone can re-ask it there in a way such that it fits & stays)

vzn
  • 11,162
  • 1
  • 28
  • 52
2

As long as the programming language in question is sufficiently complex (i.e. if it is Turing complete), then there are always programs in the language which no program can prove to terminate.

Since all but the most primitive languages are Turing complete (it only takes something like variables and conditionals), you could really only build very small toy languages for which you could solve the halting problem.

Edit: In light of the comments, let me be more explicit: Any language that you might design for which you could solve the halting problem would necessarily have to be Turing-incomplete. This rules out any language that contains a suitable set of basic ingredients (e.g. "variables, conditionals and jumps", or as @sepp2k says, a generic "while"-loop).

Apparently there exist several practical "simple" languages like that (e.g. theorem solvers such as Coq and Agda). If those satisfy your notion of a "programming language", you might investigate whether they satisfy some sort of completeness, or whether the halting problem is solvable for them.

2

Consider some formal theory $T$. Consider TMs augmented with proofs in $T$ that they halt/do not halt. Then we can decide whether a given TM-proof pair is halting by verifying the proof. (The examples given in sepp2k's answer are special cases).

This is quite trivial. If we take the union of any c.e. subset of halting TMs and any c.e. subset of non-halting TMs, the result will be set of TMs for which the halting problem is decidable (run both machines in parallel, if the first one accept the TM halts, if the second one accepts then the machine does not halt). However this will not lead to much interesting languages.

The reason is simple: in practice, we usually don't care if a program halts on one particular input but when if it halts on set of inputs, and in that case we have a universal quantifier which cannot be verified as soon as programs are expressive enough. How expressive? A very small amount of expressiveness is sufficient (e.g. $\mathsf{ALogTime}$). As soon as the programs are powerful enough to express if a given string $c$ is a halting computation of a Turing machine $M$ on a blank input (a completely syntactic problem that can be solved quite easily) then the halting problem for those programs becomes undecidable.

Kaveh
  • 22,661
  • 4
  • 53
  • 113
1

Yes you can, but I doubt it will be useful. You'd probably have to do it be case analysis and then you'd only be able to look for the most obvious cases. For example, you could grep a file for the code while(true){}. If the file has that code it will never terminate^. More generally you could say that a program with no loop or recursion will always terminate and there are several cases you could do that could guarantee that a program will or will not terminate, but for even a mid-size program this would be very difficult and in many cases would not be able to give you an answer.

tl;dr: Yes, but you won't be able to have it be useful for most useful programs.


^ Yes, technically if that code is not on the code-path or there are other threads it could still terminate, but I'm making a general point here.