Vini Psmaker argues Pratt parsing tutorials miss the point
A blog post argues that most Pratt parsing tutorials focus on implementation over the conceptual framework that actually matters.
What to know
- Most Pratt parsing tutorials focus on algorithm implementation rather than the conceptual framework that matters for practical use.
- The core idea—"what do we expect to see to the left of a token?"—is more valuable than memorizing the 9-line code snippet.
- Pratt parsing has remained unchanged since 1973 and is best approached as a mindset for thinking about parsing, similar to how developers use quicksort without understanding its internals.
Pratt parsing's value lies in the conceptual framework, not implementation mastery.
-
“I used Pratt parsing in the compiler for a macro-heavy language…Pratt fundamentally changed the design of my language by allowing metaprogramming stuff that I never dreamed of.”
vinipsmaker · Lobsters ↗
The mutual recursion between nud() and led() functions is a critical technical detail that shouldn't be overlooked.
-
“In the opening code snippet, I think a VERY important point is that both `nud()` and `led()` will typically call back into `expression()` (after the Pratt logic dispatches to the right one).”
andyc · Lobsters ↗
Vini Psmaker Blog post author, compiler developerDouglas Crockford Parser theorist (cited)
How it unfolded 8 developments, newest first · click a bar or a number to jump postscomments
-
8
Conartist6 clarifies BABLR as push parser with LR mechanics
A Lobsters commenter clarifies that BABLR is actually a push parser held by grammar control, with LR semantics and special shift instruction handling for infix grammars, not a Pratt parser.
-
> Is it a pratt parser? No. Briefly skimming that file (I spent a few minutes trying to chase definitions across repos before I gave up), it _looks_ like a conventional recursive-descent pull parser, where pulling is implemented via generators. You could also be using the generators for backtracking but I don't see any evidence of that in this…
2 more of the top 3 · 9 posts in this stretch
-
Tangential - on the 'use [] instead of <>' advice that you referenced in the post, I wish more languages would experiment with making types first class values that just get passed in regular () braces instead.With erased static types, you can do arbitrary operations on types-as-values at compile time and just compile the static result into the…
-
It's actually a push parser though! The thread of control is held by the grammar not the core. Wherever you see `eatMatch` parsing can backtrack, but otherwise it's LR. It uses a special shift instruction to handle infix grammars.
-
-
7
Vinipsmaker acknowledges parsing philosophy alignment
The post author responds to a fellow parser expert, noting that they discovered their writing after already developing their own compiler along similar lines and admiring their approach to parsing problems.
“from any person alive, I think you're the one with the parsing mindset closest to my own…”
— vinipsmaker -
I only found/stopped to read/paid attention to your blogposts on the topic of Pratt parsing after my project/language was already deep on “Pratt rails”, but I must say... from any person alive, I think you're the one with the parsing mindset closest to my own (when it comes to parsing problems). This time I'll probably copy your design on eggexes…
-
-
6
Parser developer andyc highlights mutual recursion in Pratt implementations
A Lobsters commenter with prior parsing writing emphasizes that both nud() and led() functions typically call back into expression(), making Pratt parsing fundamentally mutually recursive like recursive descent.
“In the opening code snippet, I think a VERY important point is that both `nud()` and `led()` will typically call back into `expression()` (after the Pratt logic dispatches to the right one).”
— andyc, Lobsters commenter, parser developer · source -
I'm glad to see more explorations of Pratt parsing :-) And thanks for referring to previous writing, including my own! In the opening code snippet, I think a VERY important point is that both `nud()` and `led()` will typically call back into `expression()` (after the Pratt logic dispatches to the right one). There's no getting around that…
-
-
5
Conartist6 asks for parser classification of BABLR
A Lobsters commenter questions whether BABLR (a grammar-based parser) should be categorized as a Pratt parser, sparking technical discussion about parser taxonomy.
-
I still wish to know: what would people categorize BABLR as? Is it a pratt parser?
1 more of the top 2 · 2 posts in this stretch
-
Looks like something to do with Typst and its "zebraw" package:
-
-
4
Technical issue notedCode blocks repeated four times in rendering
A Lobsters commenter points out that the blog post's code blocks appear repeated four times due to what appears to be a Typst HTML styling issue, affecting both Chrome reading mode and Firefox.
-
There are in fact four complete copies of each code block as it looks the typst html styling in use seems to use four separate divs each containing the full text content and then do some selective display or something of them for color schemes and stuff. Chrome reading mode also behaves the same rendering all four copies.
1 more of the top 2 · 2 posts in this stretch
-
I don't know what could possibly be causing this, but in Firefox's reading mode the contents of every code block are repeated four times.
-
-
3
Pervognsen recommends Lean's approach to self-extensible parsing
A Lobsters commenter points to Lean's implementation of Pratt parsing in self-extensible languages, noting how dependent typing forces single-pass execution with natural synchronization boundaries.
-
For Pratt parsing as a component of a self-extensible language like this, it's worth checking out what Lean does. Most dependently typed languages require explicit forward declarations and other things that already force them to run in a single pass at the top level. In Lean's case, the top-level granularity is one command-like item executed in a…
-
-
2
Psmaker shares personal experience using Pratt in compiler design
In a Lobsters comment, Psmaker describes using Pratt parsing in a macro-heavy compiler project for nearly a year, noting that it fundamentally changed the language design by enabling metaprogramming capabilities.
“Pratt fundamentally changed the design of my language by allowing metaprogramming stuff that I never dreamed of.”
— vinipsmaker -
I used Pratt parsing in the compiler for a macro-heavy language that I've been developing for almost a year before finally sitting down on my chair to write my thoughts on Pratt parsing. The code is closed right now because I don't want LLMs training on my code before the public release for 0.1, but what I can say is that Pratt fundamentally…
-
-
1
Vini Psmaker publishes essay on Pratt parsing pedagogy
A blog post titled "Pratt parsing is a black box" argues that most tutorials focus on the algorithm's implementation rather than the conceptual framework behind it. The post asserts that understanding Pratt as a mindset about parsing is more important than memorizing code.
“And here's a secret: that's the least important thing you need to understand about Pratt's. In fact, you don't need to understand this piece at all!”
— Vini Psmaker -
1 outlet Pratt parsing is a black box
first by HN Frontpage, 8d ago
-
What people are saying 6 voices from 1 site · best of 17 · verbatim
- Nov 4
-
"Pratt can't parse statements" - can't you treat ';' as an operator whose meaning is "then"? You can then read "DOTHIS(); DOTHAT()" as an expression.
- Nov 3
-
Is this the same algorithm commonly known as "recursive descent" parsing and one of the oldest parsing algorithms? The array index example is just recursive descent and the expression parsing is recursive descent with abstracted operators instead of a parsing function per precedence level.GCC used to use a type of parser generator but switched to…
-
I've written a few Pratt parsers in my time. You don't need a lexer and you can have more parser states than are implied by 'nud' and 'led'. They can be incredibly extensible. For example, if you can parse the expression "{a:1, b:2}" then you might naturally have an Expr state (nud), a Between state (led) and a DictKey state; that might initially…
-
I'd like to see a bit more about how compares to peg or something like ohm/ometa - am I correct assuming you pretty much give up the benefits of a readable grammar as documentation?Maybe I just need to see something super simple like a calculator with expressions side by side to grasp the trade-off?
-
Author here.I was using Pratt parsing for almost a year in a macro-heavy language that I've been developing before finally sitting down on my chair to write my thoughts on Pratt parsing. Code is closed right now because I don't want LLMs training on my code before 0.1, but I'll open source it again later.Happy to answer questions.
-
> Traditional parsing techniques register semantic actions to production rules.Are there any professional slop interpreters who can explain what this means?