Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Fair enough. I've definitely run into many of those issues too. It sounds like the features you're missing are:

- an ability to switch some blocks of input text to an alternative parser for another language or more free-form mode

- a better model of CFGs that reduces or eliminates unnecessary errors from the tool not understanding your particular normalization of the grammar

- better tools for working with the resulting ASTs

It sounds to me like the real issue is with the tools we have, not necessarily with parser generators as a concept. Maybe a more accurate title would have been "why today's parser generators don't work for me", because at the end of the day, unless your really good at cranking out sensible parsing code on your own, going the ad-hoc route seems to have a huge drawback when it comes to reinventing the wheel and maintenance of the resulting parsing code. The other major advantage of using a parser generator in my mind is that the resulting language is likely to be way more consistent and portable than something that's parsed ad-hoc. But maybe for simple languages, this isn't a big deal.



If the tools are still seriously lacking after several decades, that does point at a problem with the concept IMO. I don't think the core idea of a parser generator is an awful one, but I do think it's become clear that the classic lex/yacc approach is the wrong one, and while PEGs and things like Parsec as a good step in the right direction, I think another conceptual shift will be needed before they're unambiguously better than a handrolled parser.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: