M030: Literal Matching
Comparing a fully loaded literal in one loop avoids repeated input-loading checks and examined-position bookkeeping for each character.
Mechanism and Invariants
matchLiteral compares against loaded input, then updates position and examined
range. A mismatch still leaves position after the matched prefix and examines
the differing character. Lazy stream input keeps its reader-aware fallback. VM
literal arrays are prepared once; generated literal matchers use their runtime's
input representation. Short in-place Go comparisons and unboxed action text
comparison have independent eligibility. Case-insensitive literals have no in-place or
whole-input path: generated runtimes match them rune by rune through Peek
(MatchLiteralFold), and the VMs use the folded string instruction STRF. See record
119.
Scope and State
Default loaded-input matching in closure, both VMs, generated Go Node/typed Go and TypeScript, with representation-specific implementations. Stream fallback remains necessary.
Reference Control
No universal same-source per-character-bookkeeping reference control exists.
Evidence and Implementation
Historical record 032 measures 1.5–7% faster sampled closure/recursive VM workloads except unchanged CSV VM timing. It does not establish current TypeScript, stream or all-literal benefits.
Evidence records: 032.
Source owners: parser.matchLiteral,
generated literal matcher,
TypeScript literal matcher.
The comparison policy distinguishes same-source controls, historical changes and full checkpoints.