Formal notion of a call graph for Turing machines

Question

To most computer programs one can assign a "call graph". Is there a formal notion of call graphs of Turing machines?

Motivation is, that one could intuitively call a decidable language $L$ "irreducible" if every Turing machine which decides $L$ has a "trivial call graph" (Trivial here intuitively means, that the machine $M$ which decides $L$ can not call another machine $M'$ during the computation on words). This would intuitively correspond to the notion that "irreducible problems" cannot be solved by breaking them up into smaller problems, for example by divide and conquer.

Another motivation is to understand the concept of composition of Turing machines, which is "equivalent" to understand what is meant when one speaks of "subroutines" (which one could call a "submachine").

Answer 1

Turing machines have no concept of "calling".

Tou can jump to another state and that can look quite a lot like a procedure call, especially if an author's description of the machine in English uses words that make it sound that way. But that's all you can do. In particular, there's no notion of "return" in a Turing machine. There's no way to say "OK, this procedure is finished – now go back to wherever we came from." All you can do is say "OK, this procedure is finished – now go to this specific point."

Of course, because Turing machines are Turing powerful, you can simulate these things. For example, you can write some notion of a return address on the tape as part of your simulation of a procedure call. But that's not intrinsic to Turing machines: it's just a property of the particular Turing machine you're writing at the moment. A coding convention, if you like.

Answer 2

For TMs, there is no such notion and there can not be. Compare plain TMs with assembler: there are rudimentary operations which together create some effect, but there is little to know syntactic structure.

The concept of procedure calls you have in mind only exists in higher-level programming languages, namely such that have introduced abstractions you can use to modularize your code in a clear way. Compilers take these concepts and translate them into rudimentary code: procedure calls become unconditional jumps with some maintenance code around them.

Looking at the compilate, you won't be able to determine a call graph per se: there are no procedures anymore, just a huge blob of code with jumps in all directions.

The situations with TMs is similar. In proofs, we use higher-level descriptions in an informal way; we expect that every informed reader would, in principle, be able to create a real TM following our sketch -- to compile, essentially. The resulting machine would bear little resemblance to the original description.

Of course, you can happily talk about "call graphs" in these languages -- just don't expect the notion to carry over to TMs any more than a call graph in C carries over to, say, MIPS assembler.

Answer 3

Quoth Hopcroft and Ullman:

A Turing machine can be formally defined as a 7-tuple $M = \langle Q, \Gamma, b, \Sigma, \delta, q_0, F \rangle$ where

• $Q$ is a finite, non-empty set of states
• $\Gamma$ is a finite, non-empty set of tape alphabet symbols
• $b \in \Gamma$ is the blank symbol (the only symbol allowed to occur on the tape infinitely often at any step during the computation)
• $\Sigma\subseteq\Gamma\setminus\{b\}$ is the set of input symbols
• $\delta: (Q \setminus F) \times \Gamma \rightarrow Q \times \Gamma \times \{L,R\}$ is a partial function called the transition function, where $L$ is left shift, $R$ is right shift. (A relatively uncommon variant allows "no shift", say $N$, as a third element of the latter set.) If $\delta$ is not defined on the current state and the current tape symbol, then the machine halts.
• $q_0 \in Q$ is the initial state
• $F \subseteq Q$ is the set of final or accepting states. The initial tape contents is said to be ''accepted'' by $M$ if it eventually halts in a state from $F$.

Note that lack of a notion of "calling" anything. A Turing Machine executed the steps prescribed by its transition function. There is nothing you could call, because there is no program, no notion of a method, nothing but the transition function.

Other formalisms might be more amenable to defining a call-graph. Things like a RAM for example.