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

This is nice, but when your language will grow, why would you use that instead of lex/yacc? It's hard to beat a nice BNF grammar; In fact they felt the need to put the BNF grammar for the things they were parsing at the end of the README, because it's far more readable that those >* skip <* stuff.


A good thing about parser combinators like this is that they’re unambiguous by construction.

I also find them much more controllable and manageable in practice. I think that’s a common experience with imperative parsing in general, as it’s the approach used in I’d say the majority of industrial compilers.

> It's hard to beat a nice BNF grammar; In fact they felt the need to put the BNF grammar

The BNF grammar there is incomplete compared to their actual code, it’s just a sketch it doesn’t completely describe the accepted language, so hard to argue it’s better as you wouldn’t be able to do anything with it!


True the BNF grammar is easier to read but using lex/yacc doesn't mean easier to read: https://sites.ualberta.ca/dept/chemeng/AIX-43/share/man/info...

I much prefer parser combinators over anything else I've tried that generates code.


Most language parsers don't use lex/yacc. Recursive descent, PEG and similar are more common.


imo parser combinators are vastly easier to use, read and write than lex/yacc.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

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

Search: