Pimp My IDE / parser inspection
Back to garage
Parsing / error position / 18 Oct 2026

Make the parser show its work.

Small text formats do not need one giant regular expression. Build named parsers, feed the remaining input forward, and keep the failure position visible.

A parsed value is incomplete evidence if the parser leaves unexplained input behind.
PING host=1.1.1.1 count=3
verbhostcounteof

Three stages consumed input. The full-input check is still open.

A parser can be a row of small functions.

Florian Schindler's parser-combinator tutorial starts with a direct TypeScript type. A parser receives a string and returns a value with the rest of that string. The tutorial builds sequence, map, and repeat operations by combining parsers into new parsers. Its larger example turns ping output into named data.[1]

That design fits the gap between a dense regular expression and a full grammar tool. Each parser owns one rule. Sequence passes the remaining input to the next rule. Map turns an intermediate tuple into the data shape the caller needs.

The remaining input is part of the result, not cleanup.

Consumption changes the meaning of failure.

The original Parsec paper distinguishes failure before input consumption from failure after consumption. Its left-biased choice operation tries the next alternative only when the first parser has not consumed input. This restriction avoids retaining the original input for arbitrary backtracking. It also helps the parser report the position and legal grammar productions at the failure point.[2]

This is an operational rule, not a reason to make every parser commit early. It means parser authors must decide where alternatives belong and where lookahead is needed. The paper also states a known limit. A left-recursive parser calls itself before consuming input and loops unless the grammar is rewritten or a suitable combinator handles the pattern.

Keep state and errors inspectable.

Megaparsec exposes the remaining input, processed-token offset, source position, and delayed parse errors in its parser state. Its main interface also names operations for labels, lookahead, controlled retry, recovery, full-input checks, and custom failures.[3]

A useful development view should mirror those facts. Show the current offset. Show the unconsumed suffix. Name the rule that failed and what it expected. Require an end-of-input check when the format must consume the whole string. A green parsed object without that last check can accept a valid prefix and ignore a bad tail.

Test the grammar at its seams.

  1. Keep one valid fixture with the shortest legal input.
  2. Keep one valid fixture with the longest or most varied legal fields.
  3. Cut the input after every stage and check the reported expectation.
  4. Add a valid prefix followed by junk and require the full-input check to fail.
  5. Exercise every alternative at the first token where its route differs.
  6. If the parser retries, record whether the failed branch consumed input first.
Interactive makeover / input plus trace plus fixture

Parser circuit trace bench

A normal text field reports pass or fail. This bench also shows each grammar stage, the consumed prefix, the remaining suffix, and a copyable test fixture.

Feed the grammar

Edit the command or load a seam case. The parser runs in this page and does not send the input anywhere.

command := "PING" space host space count eof
host    := "host=" ipv4
count   := "count=" integer

This teaching parser checks four decimal IPv4 parts but does not limit each part to 255. It demonstrates parser state, not network-address validation.

Valid commandOffset 25 of 25
Verb
Host
Count
Map
EOF

All grammar stages passed. No input remains.

Consumed prefixPING host=1.1.1.1 count=3
Remaining input[empty]
Sources read / 18 Oct 2026

Evidence locker

Current tutorial

Parser combinators

Builds partial parsers, sequence, map, and repeat operations in TypeScript, then uses them to parse ping output.

Read Florian Schindler's tutorial
Original design paper

Parsec

Explains consumed versus empty replies, predictive choice, backtracking costs, error labels, and the left-recursion limit.

Read the Parsec paper
Library documentation

Megaparsec

Documents parser state, offsets, remaining input, error bundles, labels, lookahead, retry, recovery, and end-of-input checks.

Read the Megaparsec module docs