3 ms·
I wrote a simple compiler during uni, and a syntax highlighter for a commercial product in 2002. I consider myself competant with grammars. Yet I hardly ever de
by tlarkworthy 14y ago
I wrote a simple compiler during uni, and a syntax highlighter for a commercial product in 2002. I consider myself competant with grammars. Yet I hardly ever deploy my parsing skills in everyday programming, even though I know most protocol interpreters, file readers etc. would befitting from the readability that grammar and parsing separation achieves. I never use parsers because the "compile the compiler" then "compile the generated code" is horribly cumbersome. Also, the time taken to remember grammar syntax and get back in the mindset of grammar writing takes a 10 min regular expression hack stretch into 2 weeks of dev time (I am constantly switching languages so its not like ever use the same parser generator twice).
^^ was true a month ago until I met peg.js (http://pegjs.majda.cz/online http://pegjs.majda.cz/online). You can try out the grammar live, without compilation on example data! This now means you can rapidly prototype a grammar and even logic within it (in JS). Even if you are not targeting a JS embedded parser, it still lets you work out your grammar ready to translate into another language.
Since discovering peg.js I have applied proper parsing technology twice in a month for relatively trivial tasks. I would have never bothered before. I really recommend this tool for programmers who find the inertia of getting out the parsing big guns too much to bother.
- tikhonj 14y agoParser combinators, like Haskell's Parsec, are another popular option like this. They're also much more lightweight than a parser generator. In Haskell, people almost never use regular expressions, and Parsec is part of the reason. Anything trivial can be done just with library functions, and anything that would require a non-trivial regexp are both far easier and far more readable with Parsec.