Pratt parsing is a black box

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.

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?

https://ohmjs.org/

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 accept just an identifier and a colon before recursing into Expr state, but you could later add dynamic expressions, perhaps via a macro, to support [expr] as a key.

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 recursive descent because the C language is just a little bit too dynamic to make it work well (EG typedefs). They specifically cited the advantage that because you are writing actual code to parse each production rule, you can break the conventions when needed.

> Traditional parsing techniques register semantic actions to production rules.

Are there any professional slop interpreters who can explain what this means?