PEGO

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.

Related mechanisms: M070, M120, M130.

Optimization Catalog