marser aims to make Rust parser combinators read like EBNF

marser aims to make Rust parser combinators read like EBNF

Rust parser combinators are usually judged on speed, flexibility, and error quality, but Arne Debo’s marser experiment asks a simpler question: can the code still make sense when you come back to it a month later? That is the promise behind a grammar-first approach that tries to separate the shape of a language from the code that builds its AST, so the parser reads more like an EBNF specification than a chain of nested combinators.

What marser is trying to fix

If you have written nontrivial parsing code in Rust, the pain points are familiar. Powerful libraries like nom and chumsky can express a lot, but real grammars often turn into intermediate values, tuple juggling, and logic that is harder to scan than it should be. Debo frames marser as a response to that exact mess: an experiment that keeps PEG-style matching, but presents the grammar in a more direct form.

That framing matters because marser is not being sold as a finished replacement for the established crates. It is an active experiment, which makes it more interesting as a design signal than as a production recommendation. The question it raises is practical rather than academic: if the grammar itself can stay readable, does that lower the cost of maintenance enough to matter in hobby projects, small tools, and language experiments?

Grammar first, AST second

The core idea is to write the grammar directly in Rust code and then use a capture-style macro to parse input. That keeps the syntax close to the way Rust developers already define types and validation logic, which reduces the mental jump between “what the language looks like” and “what the parser does.” Instead of treating parsing as a maze of combinators first and a grammar second, marser tries to make the grammar the main object.

Debo walks through that with examples such as a simple dice-notation grammar and a function-signature parser. Those are good examples for this style because they are small enough to understand quickly, but structured enough to show the real tradeoff: the code needs to express sequence, alternation, and captured values without burying the actual shape of the language. If marser works, you should be able to read the grammar and recognize the language almost line for line.

That readability goal is the real draw. In an EBNF-like layout, the parser stops looking like a pile of transformation steps and starts looking like a specification. For a Rust developer who has not touched a parser in weeks, that can be the difference between “I remember what this does” and “I need to reconstruct the whole thing from scratch.”

The bar is higher than syntax

Marser is not just about prettier code. Debo also emphasizes three qualities that determine whether a parser library stays a toy or becomes useful in real software: diagnostics, error recovery, and performance. That is the right bar, because a parser that looks clean but falls apart on bad input is not much help in an editor, compiler, or protocol implementation.

This is where the comparison with nom and chumsky becomes useful. Nom describes itself as a parser combinator framework focused on safe parsing, streaming patterns, and zero-copy. Its error-management docs are explicit about the goals: identify which parser failed and where, accumulate context, stay low-overhead, and remain customizable. Chumsky, meanwhile, advertises recursive-descent parsing of PEGs, context-sensitive grammars, zero-copy parsing, flexible error recovery, caching, Pratt parsing, left recursion support, memoization, and no_std support.

That combination sets a high benchmark for marser. A grammar-first API may be easier to read, but if the errors are vague or the recovery story is weak, the ergonomics advantage disappears fast. For real-world use, the nicest syntax in the world still has to survive malformed input without turning debugging into a guessing game.

How the older parser crates shape the comparison

Combine is a useful historical reminder that Rust parser combinators have been exploring these tradeoffs for a long time. It is an older library inspired by Haskell’s Parsec, and it defaults to LL(1) parsing with opt-in arbitrary lookahead through an attempt combinator. That design shows the same pattern the Rust ecosystem keeps revisiting: make the common path straightforward, then leave escape hatches for harder grammars.

Nom, chumsky, and combine each answer a different question. Nom is the seasoned choice when you want safe, fast, zero-copy parsing and are comfortable shaping the combinators yourself. Chumsky pushes harder on expressiveness and recovery, which is why it often comes up as a better fit than nom for human-writable inputs and tooling where error recovery matters. Combine sits in the background as a reminder that lookahead strategy and grammar control are long-standing concerns, not new ones.

Marser enters that landscape with a narrower pitch: make the grammar read cleanly first, then keep the rest of the parser architecture close enough to Rust that it stays practical. That is a meaningful angle, especially if your work leans toward DSLs, configuration formats, or small domain-specific languages where readability is part of the feature set.

Where marser fits for hobby projects

For hobby projects, the tradeoff is especially visible. A parser that is easy to sketch but hard to revisit can become technical debt the first time you pause the project for a few weeks. A grammar-first style has obvious appeal there because it lowers the barrier to re-entry: the rules look like the language, the captures stay local, and the structure is easier to verify by eye.

But the same hobby setting also makes the limitations matter. If you need rich diagnostics for user-facing input, you will care a lot more about how errors are reported than whether the syntax is elegant. If you are building a tiny command-line parser, speed and simplicity may matter more than advanced recovery. Marser’s value, then, is not that it replaces nom or chumsky, but that it offers another point on the design map, one that prioritizes the way humans read the grammar.

That is why Debo’s article lands as a useful Rust ecosystem note rather than a product announcement. It reflects a familiar pattern in the community: developers keep probing the boundary between expressiveness and maintainability, looking for parser code that is both powerful and legible. Marser’s EBNF-like goal suggests that the next round of parser ergonomics may be judged less by how clever the combinators are and more by whether the grammar still feels obvious when you open the file a month later.