+ A Tape Machine (TM) is an abstract mechanism for manipulating data found in sequences. Such sequences include lists, arrays, sets (given an ordering function), and maps (also given an ordering function). Also included are linear traversals of more complex structures. The theory underpinning the TM is discussed in the TTCA book.
+
+
+
+ Unlike standard arrays (which are stateless) or iterators (which are transient), a TM combines a data substrate with a persistent head. The head maintains positional state, allowing the programmer to navigate, read, and write tape cells.
+
+
+
+ Thus a TM packages both data, and all pointers into that data, within one structure.
+
+
+
+ A TM can have a concrete tape or a virtual tape. A concrete tape is backed by a container. A virtual tape presents the same TM interface, but its cells and motion are implemented by functions over some internal state. For example, an abstract Counting Number tape machine can use a big integer as its state and implement stepping and reading over that state, instead of traversing an array of numbers.
+
+
+
+ A defining invariant of all Tape Machines is that cell contents are cargo. The TM reads and writes cell payload, but it does not interpret that payload as control. The decisions are made above the TM, by the programmerâs algorithm.
+
+
+
+ A first order TM is defined by a single invariant: the head is always on a valid cell. This invariant makes the primitive interface total: every move, read, write, and query has a clean, well defined meaning, and caller code stays free of scattered end case tests.
+
+
+
+ If an operation were permitted to remove the last remaining cell of a tape, said first order invariant would be broken and the interface would stop being total. A working TM that supported such a deletion would need status logic that represents the empty state. That status logic would either be embedded inside the TM operations as edge handling, or be represented explicitly as a separate status machine layered above the base TM. Either choice represents a shift in level of analysis being done, and therefore would lead to the construction of a distinct second order tape machine.
+
+
+
+ Tape machines that share a tape are said to be entangled. There will be both data and structure hazards among entangled machines. Data hazards have to do with the misuse of locks or other mistakes in cooperation between machines that cause a machine to read the wrong data. Data hazards can lead to incorrectly computed results, but they will not break the machines. In contrast, structure hazards lead to broken machines. The principle structure hazard is that of one entangled TM deleting a cell that another TM has its head on. That orphans the head of that other machine and leads to a violation of the a tape machine head is always on a valid cell invariant.
+
+
+
+ We leave the data hazard management to the programmer; however, we provide specific features for avoiding structure hazards.
+ These are selected at TM construction time. In one approach, no methods are placed on the interface that can destroy tape cells. This supports a non-destructive programming paradigm, so such machines are said to be non-destructive. Without destructive operations, entangled machines simply do not have the ability to break each other. In a second approach, the interface is configured so there are no functions for entangling machines in the first place. Each solitary machine can safely perform destructive operations because no other machine shares its tape. As a third approach, each group of entangled machines shares a catalog listing all machines in the group. Caller code can guard operations by querying whether a planned operation is safe before attempting it. This third strategy is called entanglement accounting. During the time of execution of the guard and operation, each tape machine must be able to lockout others from access to the catalog. Yet another approach is for the programmer, compiler, or external function to prove code is safe, which is the same as proving that guard code is not needed. An alternative is to use a compiler that only produces correct code in the first place. This is the approach of correct by construction.
+
+
+
Machine Naming Convention
+
+
+ Concrete Tape Machine classes follow a strict naming grammar. This grammar acts as a feature descriptor, allowing the programmer to select a machine by constructing its name.
+
+
+
+ The name is composed of three feature segments: the Container Type, the Chirality, and the Entanglement Approach.
+
+ Segments are separated by underscores. The default configuration for a segment is used if that segment is omitted.
+ The default machine is TM_Arr_CR_ND (Fixed Array, Chiral Right, Non-Destructive).
+
+
+
container
+
+
ArrArray Fixed (Default). A contiguous sequence of fixed length (e.g., Python List, C Array).
+
ArrVArray Variable. A contiguous sequence that may resize (e.g., Vector).
+
GRGraph Right. A node-based sequence with a single right neighbor (Singly Linked List).
+
GLRGraph Left Right. A node-based sequence with left and right neighbors (Doubly Linked List).
+
SetSet. Iteration over the elements of a Set.
+
MapMap. Iteration over the items (Key-Value pairs) of a Map.
+
MapKMapKeys. Iteration over the keys of a Map.
+
MapVMapValues. Iteration over the values of a Map.
+
ASCIIAscii. A sequence of 1-byte characters.
+
UTF8Utf8. A sequence of variable-width Unicode characters.
+
+
+
chirality
+
+
CRChiral Right (Default). The machine head can only be moved to the right.
+
CLRChiral Left Right. The machine is bidirectional, supports stepping either right or left.
+
+
+
entanglement
+
+
NDNon-Destructive (Default). Safe for entanglement.
TMTTMTraversal. Algorithmic traversals over non-linear structures.
+ Example:TMT_Tree_DepthFirst (Linearizes a tree via stack/recursion).
+
+
+
Command language
+
+
+ The command language is not used directly, rather it describes the letter patterns used to form TM interface function names.
+ Such an approach can be found in LISP language list access function names, and its extension is described in the paper "Towards a Better Understanding of CAR, CDR, CADR and the Others".
+
+
+
+ The actual function names found on TM interfaces are listed in later sections of this guide. The ultimate authority is the source code itself. Later we can add a compiler for creating new functions based on this language. Such a compiler would be a function that adds functions to a TM interface.
+
+
+
+ The grammar selects which parts of the language are available based on the machine's configuration (CR or CLR).
+
+
+
For the non-destructive step right machine
+
+
grammar
+
+ statement :: ( command [arg]* )+
+ command :: e | q | r | s | w
+ arg :: R | n
+
+
+
statement
+
+ A statement is parsed left to right. Each command letter begins a new command group. All following arg descriptors attach to that command until the next command letter appears. There are no spaces. Arguments are given to the resulting function in the order that the command and its descriptors require them.
+
+
+
+ Accordingly, a function name such as snr(i) denotes two command groups:
+ sn(i) steps right i times, then r copies out the current cell.
+
+
+
command
+
+
eentangle
+
qquery
+
rread
+
sstep
+
wwrite
+
+
+
+ Two or more machines are entangled when they share one tape.
+ Entangle differs from clone because the tape is shared rather than copied.
+ What is duplicated is the head state, so entangled heads move independently.
+ A machine produced by e begins with its head on the same cell as the machine it was created from.
+
+
+
+ The query command, q, reports head state.
+ With no arg descriptor it returns a boolean value.
+ With an Rarg descriptor it returns true iff the head is on the rightmost cell.
+
+
+
+ TM uses a guard approach for end cases. Query commands appear in control flow so caller code can select the guards it needs and handle end cases explicitly.
+ When guards are unnecessary, caller code can omit them.
+
+
+
+ The r and w commands copy values to and from the current cell.
+ As of the time of this writing they are cell local operations, so direction does not enter.
+
+
+
+ The s step command moves the head to the right neighbor cell.
+ When s is given an narg descriptor, it performs n right steps.
+ On a step right only machine, n must be positive.
+
+
+
arg
+
+
nn
+
RRightmost
+
+
+
+ The narg descriptor supplies a repetition count or implies a distance query.
+
+
+
+ The Rarg descriptor focuses the command on the rightmost cell.
+ For qR, the result is true iff the head is on rightmost.
+ For sR, the effect is to cue the head to rightmost.
+
+
+
Examples
+
+
Relative head movement
+
+ s ; step to right neighbor
+ sn(1) ; step to right neighbor
+ sn(2) ; step to right neighbor twice
+
+
+
Absolute head movement
+
+ sR ; cue the head to rightmost
+
+
+
Query
+
+ qR ; true iff head is on rightmost
+ qnR ; returns number of steps to rightmost
+
+
+
Copying to and from tape cells and python variables
+
+ r ; copies cell contents to the LHS of an assignment
+ w(v) ; copies v into the cell
+
+
+
+
For the non-destructive machine that has step left
+
+
+ The step right grammar extends to left going behavior by introducing a mirror view of a machine.
+ In the mirror view, every rightward operation corresponds to the base machineâs leftward operation, so new command letters are unnecessary.
+ What is rightmost in the base view becomes leftmost in the mirror view, and vice versa.
+
+
+
+ In this extended grammar, the L prefix selects the mirror view for the command group that follows it.
+ L affects direction sensitive operations such as stepping, moving to rightmost, and scans.
+ Today r and w are cell local, so L does not change their behavior.
+
+
+
+ When L is available, n can also be negative, with the sign selecting the direction in the base view.
+
+
+
grammar
+
+ statement :: ( [machine] command [arg]* )+
+ machine :: L
+ command :: e | q | r | s | w
+ arg :: R | n
+
+
+
+ Consider a tape with cells [c_0 ,c_1 ,c_2 ,c_3 ,c_4], where c_4 is rightmost.
+ In the mirror view we write the same cells as [c_4 ,c_3 ,c_2 ,c_1 ,c_0].
+ In the mirror view c_4 sits at the left edge.
+ A right step from c_4 in the mirror view lands on c_3, which matches a left step from c_4 in the base view.
+
+
+
Examples
+
+
+ In these examples, the comments discuss what happens on the base machine. Effects in the mirror view match the same command without the L prefix.
+
+
+
Relative head movement
+
+ Ls ; step to left neighbor
+ Lsn(2) ; step to left neighbor twice
+ sn(-2) ; step to left neighbor twice
+ sn(2) ; step to right neighbor twice
+
+
+
Absolute head movement
+
+ LsR ; cue the head to leftmost
+ sR ; cue the head to rightmost
+
+
+
Query
+
+ LqR ; head is on leftmost
+ qR ; head is on rightmost
+ qnR ; steps to rightmost
+ LqnR ; steps to leftmost
+
+
+
+ The Rarg descriptor focuses the command on the selected view rightmost cell.
+ For qR, the result is true iff the head is on rightmost.
+ Under L, that rightmost cell is the base view leftmost cell, so LqR returns true iff the head is on the leftmost cell.
+
+
+
Copying to and from tape cells and python variables
+
+ r ; copies cell contents to the LHS of an assignment
+ w(v) ; copies v into the cell
+
+
+
+ The current r and w are cell local and are unaffected by L.
+ If we later support list forms or repetition forms for copy, L will affect the scan direction for those operations.
+
+
+
TM interface functions
+
+
+ This section lists the concrete methods exposed by the Python/C implementation.
+ These methods implement a selected subset of the command grammar.
+ The grammar defines a command language, while the primitive set defines the operations the library exposes directly.
+ Later sections can introduce a compile layer that accepts additional command combinations.
+
+
+
+ The L prefix is not implemented as a distinct family of primitives.
+ In the command language it selects the mirror view.
+ In the API the same effect is provided by explicit left primitives such as Ls() and Lsn(n), or by allowing a signed n on machines that support step left.
+
+
+
Navigation primitives
+
+
+ Navigation primitives implement the s command with the argument forms ε, n, and R.
+ On a step right only machine, n is constrained to positive values.
+ On a machine that supports step left, n can be negative, with the sign selecting direction in the base view.
+
+
+
+
s() steps to the right neighbor. (Command form: s.)
+
sn(n) steps by n cells. On a step right only machine, n must be positive. (Command form: sn(n).)
+
sR() cues the head to the selected view rightmost cell. (Command form: sR.)
+
+
+
+ If step left is enabled, left motion is available either as explicit primitives, or via negative n on sn(n), depending on the configured interface.
+ When explicit left primitives exist, they correspond to the mirror view command forms.
+
+
+
+
Ls() steps to the left neighbor. (Command form: Ls.)
+
Lsn(n) steps left n times. (Command form: Lsn(n).)
+
LsR() cues the head to leftmost. (Command form: LsR.)
+
+
+
+ Note the correspondence: sR cues rightmost in the base view, and LsR cues leftmost of that same underlying tape.
+ The primitives sR() and LsR() are optimized cues.
+
+
+
Input and output primitives
+
+
+ The I/O primitives implement r and w(value).
+ In the command language, r reads the current cell payload, and w(v) writes a payload to the current cell.
+ As of the time of this writing, these operations are cell local, so mirror view does not change their behavior.
+
+
+
+
r() reads the current cell.
+
w(v) writes v to the current cell.
+
+
+
+ Bulk forms can exist in the API, but they are not represented in the current command grammar.
+ They are library level conveniences built on top of repeated primitive behavior.
+ If bulk copy forms become part of the command grammar later, mirror view will affect scan direction for those operations.
+
+
+
+
rn(n) reads n cells.
+
wn(list) writes a list of values.
+
+
+
Destructive Primitives
+
+
+ Machines configured with the SO (Solitary) entanglement approach may expose primitives that modify the tape structure.
+ These are distinct from w (which modifies cell content) because they change the cell count or sequence.
+
+
+
+ Note: Not all container types support all destructive operations. For example, Arr (Fixed Array) does not support deletion or insertion, whereas ArrV (Variable Array) does.
+
+
+
Delete Neighbor (esd)
+
+ A compound-style primitive that deletes a neighbor without moving the active head.
+ Mnemonic: Entangle-Step-Delete (conceptually acts on the neighbor).
+
+
+
esd(): Deletes the immediate right neighbor. Guard: Requires not qR().
+
eLsd(): Deletes the immediate left neighbor. Guard: Requires not LqR().
+
+
+
Delete to Bound (dR)
+
+
dR(): Deletes from current to Rightmost (inclusive). Head steps left. Guard: Requires not LqR().
+
LdR(): Deletes from current to Leftmost (inclusive). Head lands on right neighbor. Guard: Requires not qR().
+
+
+
Insert/Append (esa)
+
+
esa(v): Appends value v after the current head position.
+
eLsa(v): Appends value v before the current head position.
+
aR(v): Appends value v to the Rightmost end of the tape.
+
LaR(v): Appends value v to the Leftmost end of the tape.
+
+
+
Query primitives
+
+
+ Query primitives are built from the q command.
+ On the step right only machine, the primitive set covers the boolean query forms.
+
+
+
+
qR() returns whether the head is on the selected view rightmost cell. (Command form: qR.)
+
qnR() returns number of steps to rightmost cell. (Command form: qnR.)
+
+
+
+ Mirror view query forms follow the same rule in the command language.
+ For example, LqR tests the leftmost of the underlying tape.
+
+
+
+
LqR() returns whether the head is on the leftmost cell. (Command form: LqR.)
+
LqnR() returns number of steps to leftmost cell. (Command form: LqnR.)
+
+
+
Entanglement primitives
+
+
+ Entanglement primitives implement the e command.
+ The entangled machine shares the tape with the original machine and and initially have their head on the same cell.
+ In entanglement accounting configurations, entangled machines also share the group catalog used by guard predicates.
+
+
+
+
e() returns a new entangled machine sharing the same tape. (Command form: e.)
+
+
+
+ Combined command forms such as es are legal in the grammar, but they are not required as primitives.
+ The library can expose such combinations as convenience calls, or generate them through a compile layer.
+ The core model remains that a statement is a sequence of commands applied to a selected view.
+
+
+
Usage
+
+
First order TM properties
+
+
+ For a first order TM these properties are always true.
+
+
+
+
The head is always on a valid cell.
+
All cells return a value when read.
+
+
+
+ In order to maintain these properties, a TM uses inclusive bounds for intervals, including intervals of cells.
+
+
+
Contract with the programmer
+
+
+ Some first order TM types rely upon the caller to maintain a contract.
+ Such machines typically have debug variants that add contract checks.
+ For some machines, breaking the contract limits compiler optimization.
+ For other machines, breaking the contract causes program bugs.
+
+
+
+ Contract:
+
+
+
+
When there is a right bound, the caller guarantees that he will never command the machine to step beyond the rightmost cell.
+
When there is a left bound, the caller guarantees that he will never command the machine to step left of the leftmost cell.
+
+
+
+ When traversing a tape, the contract is fulfilled by a First Rest pattern.
+
+
+
First Rest pattern with initialization
+
+
+ # Pattern 1: First Rest (Initialize with First)
+ # Useful when the accumulator starts with the first value.
+ total = tm.r() # Process First
+ while not tm.qR(): # Guard: Is there a Rest?
+ tm.s() # Step (Protected)
+ total += tm.r() # Process Next
+
+
+
+ Here tm.qR() queries whether the head is on the selected view rightmost cell.
+ It guards the step in the loop.
+ No redundant tests are done, and the loop ends without stepping off the tape.
+
+
+
First Rest pattern without initialization
+
+
+ Sometimes the accumulator is initialized to an identity value (such as zero) before the loop starts.
+ In that form, the loop and a half structure is natural.
+
+
+
+ # Conceptual "do" loop
+ do:
+ total += tm.r() # Always process the current cell
+ if tm.qR() break # protects increment from spilling over
+ tm.s() # Step only when not at the end
+
+
+
+ Python has no do statement, so the same logic is written explicitly:
+
+
+
+ # Python implementation
+ while True:
+ total += tm.r()
+ if tm.qR(): break
+ tm.s()
+
+
+
+ The middle test tm.qR() guards tm.s(), so the machine never steps beyond rightmost.
+
+
+
Region Machine
+
+
A Region Machine is a composite structure built from three entangled tape machines. It enforces the invariant that the active head remains within a specified closed interval of the tape.
+
+
Structure
+
+
The Region Machine consists of:
Left Boundary Machine: A TM marking the leftmost valid cell of the region.
Right Boundary Machine: A TM marking the rightmost valid cell of the region.
Active Machine: The TM interface exposed to the user for navigation and I/O.
+
+
Because the Region Machine relies on the First Order invariant (head always on a valid cell), a region cannot be empty. The minimum region size is one cell, where the Left Boundary, Right Boundary, and Active Head all occupy the same cell.
+
+
Behavior
+
+
The Region Machine implements the standard TM interface but constrains movement based on the boundary heads.
+
+
Step (s): The Active Head performs a step only if it is not currently on the Right Boundary cell.
s() requires not qR().
Step Left (Ls): The Active Head performs a left step only if it is not currently on the Left Boundary cell.
Ls() requires not LqR().
Query Bounds (qR, LqR):
qR() returns true if the Active Head is on the same cell as the Right Boundary Head.
LqR() returns true if the Active Head is on the same cell as the Left Boundary Head.
Cue Bounds (sR, LsR):
sR() moves the Active Head to the cell occupied by the Right Boundary Head.
LsR() moves the Active Head to the cell occupied by the Left Boundary Head.
+
+
Boundary Management
+
+
The boundaries of a region are themselves Tape Machines. This allows the region to expand or contract dynamically. Moving a boundary head changes the effective range of the Active Machine immediately.
+
+
Safety Constraint: A boundary head cannot step past the other boundary head. The Left Boundary must always be to the left of or on the same cell as the Right Boundary. Furthermore, the Active Head must not be orphaned by boundary movement. If the Right Boundary steps left past the Active Head, the Active Head is no longer valid. Therefore, boundary contraction requires checking or moving the Active Head to maintain the invariant.
+
+
TM Workspace functions
+
+
The TM_workspace namespace contains higher-level functions that coordinate multiple machines. These functions are not part of the core TM interface but operate on TMs to implement common algorithms.
+
+
Tandem operations
+
+
Tandem operations drive multiple machines simultaneously. They are useful for copying, comparing, or parallel processing.
+
+
step_tandem(tm1, tm2): Steps both machines to their respective right neighbors. Requires that neither machine is at its rightmost bound.
zip_apply(f, tm1, tm2): Applies function f to the values read from tm1 and tm2, then steps both.
+
+
Predicates
+
+
Predicates test relationships between entangled machines.
+
+
head_on_same_cell(tm1, tm2): Returns true if the heads of two entangled machines are on the same cell. This is the fundamental primitive used to implement qR in Region Machines.
+ The Tape Machine with Status (TMS) is a Second Order Machine. It wraps a standard First Order Tape Machine (TM) to provide state management and advanced lifecycle features.
+
+
+
+ While a First Order TM must always reside on a valid cell (the Head must be at a valid address), the TMS allows the machine to be:
+
+
Empty (containing no data)
+
Parked (the head is conceptually "off tape")
+
Active (functioning as a standard TM)
+
+
+
+
+ The TMS implementation uses the State Pattern (vtable swapping) to ensure that the Active state incurs zero overhead. Method calls in the active state are directly bound to the underlying First Order TM's methods.
+
+
+
States
+
+
+ The TMS manages five distinct states to handle lifecycle, late binding, and memory optimization.
+
+
+
1. EmptyTyped
+
+ The machine is logically empty and has no underlying TM instance allocated. It holds a reference to a TM class type. This supports Late Binding, allowing the TMS to be created before data is available.
+
+
+ Transitions:
+
+
append(v) → Instantiates the TM with value v, transitions to Singleton.
+
+
+
+
2. EmptyStashed
+
+ The machine is logically empty, but the underlying TM instance is preserved with exactly one "zombie" cell. This is a performance optimization to avoid deallocation and reallocation costs when a machine is cleared and immediately reused.
+
+
+ Transitions:
+
+
append(v) → Overwrites the zombie cell with v, transitions to Singleton.
+
dealloc() → Destroys the TM instance, transitions to EmptyTyped.
+
+
+
+
3. Parked
+
+ The underlying TM exists, but the TMS Head is conceptually located "outside" the tape. This state is projective, meaning it connects to both ends of the tape.
+
+
+ Transitions:
+
+
s() (Step Right) → Enters the tape at the Leftmost cell. Transitions to Singleton or Active.
+
Ls() (Step Left) → Enters the tape at the Rightmost cell. Transitions to Singleton or Active.
+
d() → Deletes the "right neighbor" (the Leftmost cell). Logic handles degradation to Empty or Singleton.
+
+
+
+
4. Singleton
+
+ The underlying TM has exactly one cell. The Head is at Address 0. In this state, the underlying TM reports both Lq (Left Query) and qR (Query Right) as true.
+
+
+ Transitions:
+
+
Ls() → Transitions to Parked (exits left).
+
s() → Transitions to Active (extends right) or raises error if bounded.
+
d() → Does not physically delete the cell. Transitions to EmptyStashed (preserving the zombie cell).
+
+
+
+
5. Active
+
+ The underlying TM has more than one cell. Methods are directly bound to the underlying TM for maximum performance.
+
+
+ Transitions:
+
+
Ls() → If Lq is true (at Leftmost), transitions to Parked. Otherwise, steps left.
+
d() → If the size degrades to 1, transitions to Singleton.
+
+
+
+
Interface
+
+
Navigation
+
+ s(): Step Right.
+
+
In Parked: Lands on Leftmost cell.
+
In Active: Steps right (guarded by qR).
+
+
+
+ Ls(): Step Left.
+
+
In Parked: Lands on Rightmost cell.
+
In Active: Steps left. If at Leftmost, exits to Parked.
+
+
+
+ park(): Explicitly moves the machine to the Parked state and cues the underlying TM to the leftmost cell.
+
+
+
I/O
+
+ r() and w(val): Read and Write operations are passed directly to the underlying TM. These are valid only in Active or Singleton states.
+
+
+
Lifecycle
+
+ append(val): Adds data to the end of the tape. Handles the transition from Empty states to Singleton.
+
+
+ d(): Delete. Removes the current cell.
+
+
In Active: Removes current cell.
+
In Parked: Removes the Leftmost cell.
+
+
+
+ dealloc(): Forces the release of the underlying TM instance, returning the TMS to the EmptyTyped state.
+