4 ms·
I've really tried to get on with parser generators, but I've found they are hard to use, hard to debug and the languages/DSLs are clunky and weird. Except for c
by iamleppert 9y ago
I've really tried to get on with parser generators, but I've found they are hard to use, hard to debug and the languages/DSLs are clunky and weird. Except for cleanroom academic implementations, or for language designers who can afford the time and resources to learn and get good at a parser generator, I've found its better to simply use regular expressions to do matching and a functional language that can build up a data structure recursively.
Another problem is a lot of them resort to clunky code generation from the grammar file, and when something goes wrong you're not debugging the grammar per se, you are stepping through a bunch of machine generated code that you didn't write yourself. So your debug process looks like make change to grammar, regenerate parser, try parsing again, loop. etc. It replaces the entire file too, so its not like you can isolate areas of the code and work on them like you would regular code. And the time to generate the parser is often times slow.
Also when runtime parsing errors do happen, often the incorrect line/column numbers are reported, and getting good descriptive parser errors is a project in and of itself after you have your grammar written and working.
- bd82 9y agoEven the creator of Antlr (Terence Parr) Said: "In my experience, almost no one uses parser generators to build commercial compilers." https://github.com/antlr/antlr4/blob/master/doc/faq/general... https://github.com/antlr/antlr4/blob/master/doc/faq/general..... (no anchors for direct link).
- nerdponx 9y agoDoes Pandoc count? IIRC it implements CommonMark in a PEG.
- bd82 9y agoI don't understand the question. I am not familiar with Haskell but from what I understand Pandoc is a group of hand crafted parsers (readers) for markup formats. How does this relate to a discussion on the relevance of parser generators / libraries? https://github.com/jgm/pandoc/tree/master/src/Text/Pandoc https://github.com/jgm/pandoc/tree/master/src/Text/Pandoc
- beojan 9y agoIf you check the Parser.hs file there, Pandoc uses Parsec.
- cwp 9y agoYacc/bison seems pretty common for stuff implemented in C.
- parrt 9y agoThe unwritten corollary of course is that "almost nobody writes commercial compilers." :) Almost all of us do, however, write parsers for data, config files, languages etc... all the time. I'd personally used ANTLR of course for all my parsing needs beyond the trivial.
- pdubroy 9y agoI agree with most of your points. Re: debugging, we tried to address this with the visualizer that we built into the Ohm Editor: https://ohmlang.github.io/editor/ https://ohmlang.github.io/editor/ If you enable "Explain parse" in the bottom right, you'll see that it shows every single step that the parser takes in interpreting your grammar. It's not perfect, but we think it goes a long way to addressing the debugging issues.
- swsieber 9y agoAgreed. They still do have there place though. I, for instance, was able to import the MySQL grammar for Antlr4 from the github Antlr4 grammar repository and got it working. I use it to mangle table names of all mysql requests during tests to be able to easily isolate tests within a single database that would otherwise stomp on each other. But I don't think I'd use one for any custom parsing, like my own compiler or any grammar I get to define.
- corndoge 9y agoI find them pretty useful, the DSLs are generally just slightly modified version of BNF which is pretty straightforward to pick up. Bison + flex is my tool of choice for extensive CLI interfaces in C projects. Regex is useful (hence flex) but for higher level constructs without reinventing the wheel I think it's hard to do much better than a parser generator.