Why not to use (f)lex, yacc or bison
tomassetti.me
Why not to use (f)lex, yacc or bison
1–10 of 91 posts
Re: Why not to use (f)lex, yacc or bison
#2Re: Why not to use (f)lex, yacc or bison
#3Maybe I was holding it wrong but in my experience ANTLR’s performance (on JVM) was abysmal.
Re: Why not to use (f)lex, yacc or bison
#4Re: Why not to use (f)lex, yacc or bison
#5Total nonsense. Bison is very reliable, Flex can be a bit finicky to set up but is also reliable.
PostgreSQL uses bison ...
Re: Why not to use (f)lex, yacc or bison
#6- no way to specify operator precedence explicitly (instead, it’s based on ordering of alternatives)
- no explanation of conflicts / ambiguities in the grammar (again, ambiguities are silently resolved based on ordering of alternatives)
- might, or might not, properly handle left recursion (by “handle” I mean, that the parser always halts)
TL;DR: LL parsing is a dead end, don’t use it.
Re: Why not to use (f)lex, yacc or bison
#7Re: Why not to use (f)lex, yacc or bison
#8Maybe I was holding it wrong but in my experience ANTLR’s performance (on JVM) was abysmal.
Re: Why not to use (f)lex, yacc or bison
#9A lot of these are things that Google Docs or Microsoft Word will notice and ask you to change. I highly recommend using one of those to write (especially if English is not your first language) and trying to understand the suggestions it makes. Your articles will come out much more readable to others.
Re: Why not to use (f)lex, yacc or bison
#10Last I checked, the interface between lex and yacc (resp flex and bison) is by mutating static global variables. Is that still the case? It always struck me as exceptionally bad design.