How to

Short guides for the problems that come up while writing a parser. Each one takes a single task, solves it against a running grammar, and says what it costs. They assume you have already parsed something — the quickstart is five minutes if you haven't.

How these are written

A guide here is task-shaped, not feature-shaped. The title is the thing you are trying to do; the page is how to do it and what it costs. Where a published package already solves the problem, the guide uses it and says so, rather than reimplementing it for the sake of an example — extension is the point of the engine, and it applies to the documentation too.

Every code sample on these pages has been executed against the published packages, and the values in the // => comments are what the engine actually returned. Where a package behaves in a way that will surprise you, the guide says so instead of quietly avoiding it.

The reference solutions are the real grammars. When a guide points at @tabnas/csv or @tabnas/expr, it is pointing at a grammar under a couple of thousand lines that you can read in one sitting — usually the fastest way to answer a question this section didn't anticipate.

Before you write a grammar

The question to ask before any of this is what already parses something close to my format? A new grammar is the expensive answer, and usually the wrong one. The packages page lists what exists; the comparisons page is honest about when another tool is the better answer entirely.

Guides

Composing grammars

Assemble a language out of pieces that already work — other sources, expression syntax, and plugins that take options.

Shaping the parse

The rule table itself: how repetition and nesting are expressed, how the engine picks an alternate, and what changes when newlines matter.

Feeding the lexer

Everything that happens before the rules run — the tokens your language needs, and the ones it should throw away.

Working on a grammar

Seeing what a grammar does, telling the reader what went wrong, and keeping it honest.

Also in the docs

Three task-oriented pages live under /docs because they double as the way in to ABNF, actions and extension. They belong to this section as much as to that one.

If none of these fit

The rule table reference is the whole format in one page, and is short enough to read end to end. The playground runs a grammar in the browser, so a guess can be checked in a few seconds. Failing both, open an issue — a question this section should have answered is a bug in this section.