102. Read Text Struct Fields Without a Struct Lookup

• Status: Removed. Tokens are named node types (type Name = node[string]), which predicates compare with text($e) == text($n) through the unboxed comparison of M120, so no struct field is read.
• Date: 2026-10-19

#Problem and Mechanism

Terminal types were replaced by text structs, type Name = { Text string }, and the repository grammars were rewritten to build them: rule name Name = t:(...) #atomic => Name{Text: text($t)}. A predicate that compared two names with text($e) == text($n) now reads $e.(Name).Text == $n.Text. Measured against the last revision before the migration, every workload stayed within noise except XML, whose end-tag predicate makes that comparison once per element: recognition became 3–19% slower depending on the backend.

A text struct already keeps its text unboxed in the node. The field read, however, first tested whether the receiver was a node, then looked the struct type up by name (in the program's type table, or in the generated structFields map) to reject an undeclared field, before reaching the text. A text struct has exactly the field Text, so a read of Text from a text struct needs none of that: the closure, both VMs and generated Go Node parsers now return the text first. Under work controls the read still takes the full route, which charges the field lookup as before, so step counts are unchanged. Typed generated Go already read string fields directly.

#Applicability

#Reproduction

All runs use Apple M3 Max, Go 1.27.1, GOMAXPROCS=16. The migration comparison builds the bench test binary at 9bd2d2d (before the migration, with its own grammars) and at d4fd8c0 (after it, without this change), and runs each from its own tree, since the benchmarks read grammars at run time. Three alternating rounds of two samples each give six samples per case:

go test -c -trimpath -o old.test ./bench   # in each tree
cd bench && ../old.test -test.run '^$' -test.benchmem -test.count 2 \
    -test.bench '^BenchmarkParse$/./^(closure|bytecode)$/^codepoints$'

with the same pattern for generated/codepoints and generated_ast of BenchmarkParse, for the closure, bytecode and generated cases of BenchmarkRecognize, and for all of BenchmarkIncremental, BenchmarkStream and BenchmarkPrepare. The change itself is measured the same way on BenchmarkParse/XML and BenchmarkRecognize/XML, d4fd8c0 against the candidate. Raw results stay local.

#Results

Migration, before this change. Median time of d4fd8c0 relative to 9bd2d2d. Bytes and allocations per operation are unchanged within 0.3% on every parse, recognition, incremental and stream case (XML generated_ast bytes +1.7%).

Incremental Document edits and fresh parses are 0.983–1.029, streaming 1.007–1.017. Preparing from source takes 7–8% longer for JSON and minilang, whose rewritten grammars have more actions to check and compile; loading .pegoc files is 0.94–1.08 with no consistent direction.

This change, on XML. Median time, d4fd8c0 → candidate:

The generated XML recognizer, 2.55 ms before the migration, is within about 6% of it again; the rest is building the Name struct values that the predicate reads, which the terminal-based grammar did not need.

#Correctness and Tradeoffs

The fast path applies only to a node marked as a text struct and only to the name Text, which such a struct always declares, so it cannot accept a read that the full route rejects. Results, errors and work-control step counts are unchanged; the equivalence suites, the generated-parser tests and the work-control accounting tests pass.

#Decision and Limits

Adopted. Grammars that read a text struct's Text in a hot predicate still build the struct; keeping such predicates on a capture of the text (t:(...) #atomic read with text($t)) avoids that cost entirely.