mathlib documentation

computability.​tm_to_partrec

computability.​tm_to_partrec

Modelling partial recursive functions using Turing machines

This file defines a simplified basis for partial recursive functions, and a turing.TM2 model Turing machine for evaluating these functions. This amounts to a constructive proof that every partrec function can be evaluated by a Turing machine.

Main definitions

A simplified basis for partrec

This section constructs the type code, which is a data type of programs with list input and output, with enough expressivity to write any partial recursive function. The primitives are:

This basis is convenient because it is closer to the Turing machine model - the key operations are splitting and merging of lists of unknown length, while the messy n-ary composition operation from the traditional basis for partial recursive functions is absent - but it retains a compositional semantics. The first step in transitioning to Turing machines is to make a sequential evaluator for this basis, which we take up in the next section.

inductive turing.​to_partrec.​code  :
Type

The type of codes for primitive recursive functions. Unlike nat.partrec.code, this uses a set of operations on list. See code.eval for a description of the behavior of the primitives.

@[simp]

The semantics of the code primitives, as partial functions list ℕ →. list. By convention we functions that return a single result return a singleton [n], or in some cases n :: v where v will be ignored by a subsequent function.

  • zero' appends a 0 to the input. That is, zero' v = 0 :: v.
  • succ returns the successor of the head of the input, defaulting to zero if there is no head:
    • succ [] = [1]
    • succ (n :: v) = [n + 1]
  • tail returns the tail of the input
    • tail [] = []
    • tail (n :: v) = v
  • cons f fs calls f and fs on the input and conses the results:
    • cons f fs v = (f v).head :: fs v
  • comp f g calls f on the output of g:
    • comp f g v = f (g v)
  • case f g cases on the head of the input, calling f or g depending on whether it is zero or a successor (similar to nat.cases_on).
    • case f g [] = f []
    • case f g (0 :: v) = f v
    • case f g (n+1 :: v) = g (n :: v)
  • fix f calls f repeatedly, using the head of the result of f to decide whether to call f again or finish:
    • fix f v = [] if f v = []
    • fix f v = w if f v = 0 :: w
    • fix f v = fix f w if f v = n+1 :: w (the exact value of n is discarded)
Equations

head gets the head of the input list: head [] = [0], head (n :: v) = [n].

Equations

pred returns the predecessor of the head of the input: pred [] = [0], pred (0 :: v) = [0], pred (n+1 :: v) = [n].

Equations

rfind f performs the function of the rfind primitive of partial recursive functions. rfind f v returns the smallest n such that (f (n :: v)).head = 0.

It is implemented as:

rfind f v = pred (fix (λ (n::v), f (n::v) :: n+1 :: v) (0 :: v))

The idea is that the initial state is 0 :: v, and the fix keeps n :: v as its internal state; it calls f (n :: v) as the exit test and n+1 :: v as the next state. At the end we get n+1 :: v where n is the desired output, and pred (n+1 :: v) = [n] returns the result.

Equations

prec f g implements the prec (primitive recursion) operation of partial recursive functions. prec f g evaluates as:

  • prec f g [] = [f []]
  • prec f g (0 :: v) = [f v]
  • prec f g (n+1 :: v) = [g (n :: prec f g (n :: v) :: v)]

It is implemented as:

G (a :: b :: IH :: v) = (b :: a+1 :: b-1 :: g (a :: IH :: v) :: v)
F (0 :: f_v :: v) = (f_v :: v)
F (n+1 :: f_v :: v) = (fix G (0 :: n :: f_v :: v)).tail.tail
prec f g (a :: v) = [(F (a :: f v :: v)).head]

Because fix always evaluates its body at least once, we must special case the 0 case to avoid calling g more times than necessary (which could be bad if g diverges). If the input is 0 :: v, then F (0 :: f v :: v) = (f v :: v) so we return [f v]. If the input is n+1 :: v, we evaluate the function from the bottom up, with initial state 0 :: n :: f v :: v. The first number counts up, providing arguments for the applications to g, while the second number counts down, providing the exit condition (this is the initial b in the return value of G, which is stripped by fix). After the fix is complete, the final state is n :: 0 :: res :: v where res is the desired result, and the rest reduces this to [res].

Equations
theorem turing.​to_partrec.​code.​exists_code.​comp {m n : } {f : vector n →. } {g : fin nvector m →. } :
(∃ (c : turing.to_partrec.code), ∀ (v : vector n), c.eval v.val = has_pure.pure <$> f v)(∀ (i : fin n), ∃ (c : turing.to_partrec.code), ∀ (v : vector m), c.eval v.val = has_pure.pure <$> g i v)(∃ (c : turing.to_partrec.code), ∀ (v : vector m), c.eval v.val = has_pure.pure <$> (vector.m_of_fn (λ (i : fin n), g i v) >>= f))

From compositional semantics to sequential semantics

Our initial sequential model is designed to be as similar as possible to the compositional semantics in terms of its primitives, but it is a sequential semantics, meaning that rather than defining an eval c : list ℕ →. list function for each program, defined by recursion on programs, we have a type cfg with a step function step : cfg → option cfg that provides a deterministic evaluation order. In order to do this, we introduce the notion of a continuation, which can be viewed as a code with a hole in it where evaluation is currently taking place. Continuations can be assigned a list ℕ →. list semantics as well, with the interpretation being that given a list result returned from the code in the hole, the remainder of the program will evaluate to a list final value.

The continuations are:

The type cfg of evaluation states is:

The main theorem of this section is that for each code c, the state step_normal c halt v steps to v' in finitely many steps if and only if code.eval c v = some v'.

inductive turing.​to_partrec.​cfg  :
Type

The semantics of a continuation.

Evaluating c : code in a continuation k : cont and input v : list. This goes by recursion on c, building an augmented continuation and a value to pass to it.

  • zero' v = 0 :: v evaluates immediately, so we return it to the parent continuation
  • succ v = [v.head.succ] evaluates immediately, so we return it to the parent continuation
  • tail v = v.tail evaluates immediately, so we return it to the parent continuation
  • cons f fs v = (f v).head :: fs v requires two sub-evaluations, so we evaluate f v in the continuation k (_.head :: fs v) (called cont.cons₁ fs v k)
  • comp f g v = f (g v) requires two sub-evaluations, so we evaluate g v in the continuation k (f _) (called cont.comp f k)
  • case f g v = v.head.cases_on (f v.tail) (λ n, g (n :: v.tail)) has the information needed to evaluate the case statement, so we do that and transition to either f v or g (n :: v.tail).
  • fix f v = let v' := f v in if v'.head = 0 then k v'.tail else fix f v'.tail needs to first evaluate f v, so we do that and leave the rest for the continuation (called cont.fix f k)
Equations

Evaluating a continuation k : cont on input v : list. This is the second part of evaluation, when we receive results from continuations built by step_normal.

  • cont.halt v = v, so we are done and transition to the cfg.halt v state
  • cont.cons₁ fs as k v = k (v.head :: fs as), so we evaluate fs as now with the continuation k (v.head :: _) (called cons₂ v k).
  • cont.cons₂ ns k v = k (ns.head :: v), where we now have everything we need to evaluate ns.head :: v, so we return it to k.
  • cont.comp f k v = k (f v), so we call f v with k as the continuation.
  • cont.fix f k v = k (if v.head = 0 then k v.tail else fix f v.tail), where v is a value, so we evaluate the if statement and either call k with v.tail, or call fix f v with k as the continuation (which immediately calls f with cont.fix f k as the continuation).
Equations

If we are not done (in cfg.halt state), then we must be still stuck on a continuation, so this main loop calls step_ret with the new continuation. The overall step function transitions from one cfg to another, only halting at the cfg.halt state.

Equations

In order to extract a compositional semantics from the sequential execution behavior of configurations, we observe that continuations have a monoid structure, with cont.halt as the unit and cont.then as the multiplication. cont.then k₁ k₂ runs k₁ until it halts, and then takes the result of k₁ and passes it to k₂.

We will not prove it is associative (although it is), but we are instead interested in the associativity law k₂ (eval c k₁) = eval c (k₁.then k₂). This holds at both the sequential and compositional levels, and allows us to express running a machine without the ambient continuation and relate it to the original machine's evaluation steps. In the literature this is usually where one uses Turing machines embedded inside other Turing machines, but this approach allows us to avoid changing the ambient type cfg in the middle of the recursion.

Equations

The then k function is a "configuration homomorphism". Its operation on states is to append k to the continuation of a cfg.ret state, and to run k on v if we are in the cfg.halt v state.

Equations

The step_normal function respects the then k' homomorphism. Note that this is an exact equality, not a simulation; the original and embedded machines move in lock-step until the embedded machine reaches the halt state.

The step_ret function respects the then k' homomorphism. Note that this is an exact equality, not a simulation; the original and embedded machines move in lock-step until the embedded machine reaches the halt state.

This is a temporary definition, because we will prove in code_is_ok that it always holds. It asserts that c is semantically correct; that is, for any k and v, eval (step_normal c k v) = eval (cfg.ret k (code.eval c v)), as an equality of partial values (so one diverges iff the other does).

In particular, we can let k = cont.halt, and then this asserts that step_normal c cont.halt v evaluates to cfg.halt (code.eval c v).

Equations

Simulating sequentialized partial recursive functions in TM2

At this point we have a sequential model of partial recursive functions: the cfg type and step : cfg → option cfg function from the previous section. The key feature of this model is that it does a finite amount of computation (in fact, an amount which is statically bounded by the size of the program) between each step, and no individual step can diverge (unlike the compositional semantics, where every sub-part of the computation is potentially divergent). So we can utilize the same techniques as in the other TM simulations in computability.turing_machine to prove that each step corresponds to a finite number of steps in a lower level model. (We don't prove it here, but in anticipation of the complexity class P, the simulation is actually polynomial-time as well.)

The target model is turing.TM2, which has a fixed finite set of stacks, a bit of local storage, with programs selected from a potentially infinite (but finitely accessible) set of program positions, or labels Λ, each of which executes a finite sequence of basic stack commands.

For this program we will need four stacks, each on an alphabet Γ' like so:

inductive Γ'  | Cons | cons | bit0 | bit1

We represent a number as a bit sequence, lists of numbers by putting cons after each element, and lists of lists of natural numbers by putting Cons after each list. For example:

0 ~> []
1 ~> [bit1]
6 ~> [bit0, bit1, bit1]
[1, 2] ~> [bit1, cons, bit0, bit1, cons]
[[], [1, 2]] ~> [Cons, bit1, cons, bit0, bit1, cons, Cons]

The four stacks are main, rev, aux, stack. In normal mode, main contains the input to the current program (a list) and stack contains data (a list (list ℕ)) associated to the current continuation, and in ret mode main contains the value that is being passed to the continuation and stack contains the data for the continuation. The rev and aux stacks are usually empty; rev is used to store reversed data when e.g. moving a value from one stack to another, while aux is used as a temporary for a main/stack swap that happens during cons₁ evaluation.

The only local store we need is option Γ', which stores the result of the last pop operation. (Most of our working data are natural numbers, which are too large to fit in the local store.)

The continuations from the previous section are data-carrying, containing all the values that have been computed and are awaiting other arguments. In order to have only a finite number of continuations appear in the program so that they can be used in machine states, we separate the data part (anything with type list) from the cont type, producing a cont' type that lacks this information. The data is kept on the stack stack.

Because we want to have subroutines for e.g. moving an entire stack to another place, we use an infinite inductive type Λ' so that we can execute a program and then return to do something else without having to define too many different kinds of intermediate states. (We must nevertheless prove that only finitely many labels are accessible.) The labels are:

In addition to these basic states, we define some additional subroutines that are used in the above:

The main theorem of this section is tr_eval, which asserts that for each that for each code c, the state init c v steps to halt v' in finitely many steps if and only if code.eval c v = some v'.

inductive turing.​partrec_to_TM2.​Γ'  :
Type

The alphabet for the stacks in the program. bit0 and bit1 are used to represent values as lists of binary digits, cons is used to separate list values, and Cons is used to separate list (list ℕ) values. See the section documentation.

inductive turing.​partrec_to_TM2.​K'  :
Type

The four stacks used by the program. main is used to store the input value in tr_normal mode and the output value in Λ'.ret mode, while stack is used to keep all the data for the continuations. rev is used to store reversed lists when transferring values between stacks, and aux is only used once in cons₁. See the section documentation.

Continuations as in to_partrec.cont but with the data removed. This is done because we want the set of all continuations in the program to be finite (so that it can ultimately be encoded into the finite state machine of a Turing machine), but a continuation can handle a potentially infinite number of data values during execution.

inductive turing.​partrec_to_TM2.​Λ'  :
Type

The set of program positions. We make extensive use of inductive types here to let us describe "subroutines"; for example clear p k q is a program that clears stack k, then does q where q is another label. In order to prevent this from resulting in an infinite number of distinct accessible states, we are careful to be non-recursive (although loops are okay). See the section documentation for a description of all the programs.

@[simp]

Pop a value from the stack and place the result in local store.

Equations

Move elements from k₁ to k₂ while p holds, with the last element being left on k₁.

Equations
@[simp]

The program that evaluates code c with continuation k. This expects an initial state where tr_list v is on main, tr_cont_stack k is on stack, and aux and rev are empty. See the section documentation for details.

Equations
@[simp]

The main program. See the section documentation for details.

Equations

We use pos_num to define the translation of binary natural numbers. A natural number is represented as a little-endian list of bit0 and bit1 elements:

1 = [bit1]
2 = [bit0, bit1]
3 = [bit1, bit1]
4 = [bit0, bit0, bit1]

In particular, this representation guarantees no trailing bit0's at the end of the list.

Equations

We use num to define the translation of binary natural numbers. Positive numbers are translated using tr_pos_num, and tr_num 0 = []. So there are never any trailing bit0's in a translated num.

0 = []
1 = [bit1]
2 = [bit0, bit1]
3 = [bit1, bit1]
4 = [bit0, bit0, bit1]
Equations

Because we use binary encoding, we define tr_nat in terms of tr_num, using num, which are binary natural numbers. (We could also use nat.binary_rec_on, but num and pos_num make for easy inductions.)

Equations
@[simp]

Lists are translated with a cons after each encoded number. For example:

[] = []
[0] = [cons]
[1] = [bit1, cons]
[6, 0] = [bit0, bit1, bit1, cons, cons]
Equations
@[simp]

Lists of lists are translated with a Cons after each encoded list. For example:

[] = []
[[]] = [Cons]
[[], []] = [Cons, Cons]
[[0]] = [cons, Cons]
[[1, 2], [0]] = [bit1, cons, bit0, bit1, cons, Cons, cons, Cons]
Equations

The data part of a continuation is a list of lists, which is encoded on the stack stack using tr_llist.

Equations
@[simp]

This is the nondependent eliminator for K', but we use it specifically here in order to represent the stack data as four lists rather than as a function K' → list Γ', because this makes rewrites easier. The theorems K'.elim_update_main et. al. show how such a function is updated after an update to one of the components.

Equations

The cfg states map to cfg' states almost one to one, except that in normal operation the local store contains an arbitrary garbage value. To make the final theorem cleaner we explicitly clear it in the halt state so that there is exactly one configuration corresponding to output v.

Equations
def turing.​partrec_to_TM2.​split_at_pred {α : Type u_1} :
(α → bool)list αlist α × option α × list α

This could be a general list definition, but it is also somewhat specialized to this application. split_at_pred p L will search L for the first element satisfying p. If it is found, say L = l₁ ++ a :: l₂ where a satisfies p but l₁ does not, then it returns (l₁, some a, l₂). Otherwise, if there is no such element, it returns (L, none, []).

Equations
theorem turing.​partrec_to_TM2.​split_at_pred_eq {α : Type u_1} (p : α → bool) (L l₁ : list α) (o : option α) (l₂ : list α) :
(∀ (x : α), x l₁p x = bool.ff)o.elim (L = l₁ l₂ = list.nil) (λ (a : α), p a = bool.tt L = l₁ ++ a :: l₂)turing.partrec_to_TM2.split_at_pred p L = (l₁, o, l₂)