Parser Combinators
- ID
- 36850
- Status
- summarized
- Published
- 18 Oct 2026, 4:19 PM
- Fetched
- 19 Oct 2026, 6:03 AM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://t3.at/blog/2026-10-17-parser-combinators/
- Source URL
- https://hnrss.org/best
Summary
- Score
- 5.5
- Created
- 19 Oct 2026, 6:03 AM
- Tags
- Audience
- developersvibe_codersai_ml_learners
What happened
A technical walkthrough of parser combinators built from one TypeScript type: `type Parser<T> = (input: string) => [T, string]`, where each parser returns the parsed value plus the unconsumed remainder. It builds up step by step — `pInteger`, `pIgnoreWhitespace`, `pSeq` (composing parsers into a `Parser<[string, null, number]>` tuple) and `pMap` (reshaping that tuple into an object like `{ greeting: "Hello", who: 100 }`) — then applies the same pattern to parse real `ping` output into a structured record with `header.targetIp: "1.1.1.1"` and the rtt/packet-loss stats. The Hacker News thread drew 206 points and 76 comments.
Why it matters
If you currently scrape CLI or log output with regex — e.g. pulling `targetIp` and `rtt min/avg/max/mdev = 47.129/115.880/388.750/112.515 ms` out of a ping dump — this shows a ~20-line typed alternative where the result type is derived mechanically from the combinators you compose, so adding a field is a type change rather than a second regex. The decision to make: reach for combinators when the text is nested or sequential (header, then stats block), and keep regex for single flat fields. It is a tutorial, not a library release, so there is nothing to adopt or migrate today.
Discussion angle
Where is the crossover between a hand-rolled combinator like `pSeq`/`pMap` and a parser generator (ANTLR, pest, PEG.js) — and what actually breaks first in the hand-rolled version: error messages, backtracking performance, or left recursion?