From: Thomas Walker Lynch Date: Fri, 6 Feb 2026 16:20:28 +0000 (+0000) Subject: sketching out more of the user manual X-Git-Url: https://git.reasoningtechnology.com/sitemap.xml?a=commitdiff_plain;h=3082f160dddadaef76f1dfa0bd1ca79ac9621aae;p=Epimetheus%2F.git sketching out more of the user manual --- diff --git a/document/TM.html b/document/TM.html index 3634c02..abeead4 100644 --- a/document/TM.html +++ b/document/TM.html @@ -23,15 +23,11 @@

Introduction

- 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. + 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. + 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.

@@ -39,44 +35,32 @@

- 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 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 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 TM is constructed with a set of feature symbols that select which parts of the interface are available. - When no feature symbols are supplied, the result is a non-destructive step right machine with no indexing. - Feature symbols can enable step left behavior (via the mirror view), and can independently enable indexing commands. + A TM is constructed with a set of feature symbols that select which parts of the interface are available. When no feature symbols are supplied, the result is a non-destructive step right machine with no indexing. Feature symbols can enable step left behavior (via the mirror view), enable random access indexing functions, and accounting for a shared tape, among other things.

- 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. + 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, 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. + If an operation were permitted to remove the last remaining cell, 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.

- TM machines incorporate various approaches for controlling entanglement, depending on which interface features are selected at 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, one machine cannot break another by changing its tape structure. - 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. - 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. + Tape machines that share a tape are said to be entangled. There will be both data and control hazards among entangled machines. Data hazards have to do with one machine writing data being read by another, either unexpectedly, or in the wrong temporal order. Data hazards can lead to incorrectly computed results, but they will not break the machines. In contrast, control hazards lead to broken machines. The principle control hazard is that of one entangled TM deleting a cell that another TM is visiting. 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. We leave the data hazard management to the programmer; however, we provide specific features for preventing control hazards.

+

+ TM machines incorporate various approaches for managing entanglement and avoiding control hazards. These are chosen as features at 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. +

Command language

@@ -305,8 +289,7 @@ If we later support list forms or repetition forms for copy, L will affect the scan direction for those operations.

- -

Primitive method reference

+

TM interface functions

This section lists the concrete methods exposed by the Python/C implementation. @@ -317,29 +300,47 @@

The L prefix is not implemented as a distinct family of primitives. - It selects the mirror view in the command language. - In the API, the same effect is provided by explicit left variants such as ls() and lsn(n). + 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. +

+ +

Feature symbols and primitive availability

+ +

+ A TM is constructed with feature symbols that select which primitive families are present. + With no feature symbols, the result is a non-destructive step right machine with no indexing. + Enabling step left adds left motion primitives (or signed n support) and mirror view semantics in the command language. + Indexing is an independent feature: when enabled, index based query and cue forms become legal and corresponding primitives become available.

Navigation primitives

- The navigation primitives implement the s command with the argument forms ε and n(int). - The left variants implement the mirror view behavior directly. + 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.

+ +

+ 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. +

+ +

- Note the correspondence: sR cues rightmost in the right going view, and LsR cues leftmost in that same underlying tape. - The primitives Rs() and Ls() are optimized forms of those cues. + 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

@@ -347,6 +348,7 @@

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.

- Bulk forms exist in the API, but they are not represented in the current command grammar. + 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.