points by e12e 4 days ago | 0 comments
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?
[–] vinipsmaker 4 days ago
[–] e12e 4 days ago
> You can use Pratt to parse languages that have grammars
Of course. I meant more that unlike with yacc or ohm - you won't have a grammar as an intrinsic artifact - you would have to maintain it and the Pratt code in sync manually?
From looking a bit more at ohm - it generates peg - and is apparently equivalent to Pratt - so I guess one can have the cake and parse it too?
[–] vinipsmaker 4 days ago
I'm not familiar with ohm/ometa, but yes, if your language is "simple" it's possible to design a framework that generates both the Pratt parsers + a grammar so you don't need to manually keep them in sync. The complexity toll will be spent on this framework though. Plus it's unlikely that you're gonna explore traits that are exclusive to Pratt parsing so Pratt parsing would be just an implementation detail that you don't need to even bother to learn. The only upside of adopting Pratt parsing here is that Pratt parsing is fast.
[–] e12e 4 days ago
I recommend having a quick look at https://ohmjs.org/ just because it's such a joyful project that present parsing in such a simple fashion.
As to benefits of Pratt, as best I can tell ohm is fast and lean - but handwriting a Pratt parser will be faster and leaner (esp lighter memory requirements).
Ohm does however handle left recursion, which could be considered a major feature of Pratt.
This is more of a question language than a parser language. If you have a language that requires a Turing-complete parser than you gave up on grammar. You can use Pratt to parse languages that have grammars.
The language that I'm implementing has procedural macros (hence the parser is Turing-complete). However it has some "structure" that I can port to a tree-sitter parser. The tree-sitter parser for my language won't be 100% accurate, but it'll capture the most important structures.