points by vinipsmaker 4 days ago | 0 comments
> am I correct assuming you pretty much give up the benefits of a readable grammar as documentation?
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.
[–] e12e 4 days ago
[–] 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.
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?