Theory Multitape_Finite_Patch
theory Multitape_Finite_Patch
imports Multitape_Finite_Control
begin
section ‹Finite-control patch combinator›
text ‹The combinator @{text finite_patch} wraps an arbitrary machine
‹M› with a finite-control front end deciding the short inputs (length
at most a cutoff ‹N›) by a caller-supplied table, while long inputs
(length above ‹N›) are handed to ‹M› unchanged. Unlike the alphabet
combinators it performs ∗‹no encoding›: it keeps ‹M›'s input alphabet,
tape alphabet, blank, left endmarker, and tape count, so running ‹M›
is a pure state relabelling (@{text "FP_Run q"} mirrors ‹M›'s state
‹q›) on the very same tapes.
The front end scans the input read-only as the recogniser does; once
it has read past the cutoff it walks the head back to the origin
(phase @{text FP_Rewind}) and enters ‹M›'s start state, so the handoff
configuration is exactly ‹M›'s initial configuration. Short inputs
are decided in place: the scan ends on the end-of-input blank and
jumps straight to ‹M›'s accept state (identify-with-run, so no extra
halting funnel) when the table holds, or to a dedicated reject sink
otherwise.›
subsection ‹Patch state space›
text ‹Four phases: @{text "FP_Scan u"} has read the prefix ‹u›;
@{text FP_Rewind} is walking the head back to the origin after a
long-input overflow; @{text "FP_Run q"} is running the wrapped
machine in (relabelled) state ‹q›; @{text FP_Rej} is the short-input
rejection sink. Acceptance is identified with ∗‹reaching ‹M›'s accept
state under the run relabelling›, @{text "FP_Run (t_tm M)"}.›