> ANTLR uses an algorithm [...] called ALL. Why is the tool called ANT LR if it uses an LL algorithm? Did earlier versions use LR, or is it just a confusing name?
[deleted]
Why not to use (f)lex, yacc or bison
41–50 of 91 posts
Re: Why not to use (f)lex, yacc or bison
#42Is it not the case that most serious parser implementations are hand-written? In part because it makes it so much easier to provide good diagnostic messages. I feel like every other project moves from parser-generators to hand-rolled parsers and levels.
Both go and OCaml use LR parser generators, precisely because they make it easy to give excellent error messages.
Basically the key insight is that you can use the parsing automaton state to classify syntax errors, which makes it as easy as falling off a log to produce good messages. The paper originating this technique is Clinton Jeffery's TOPLAS 2003 paper “Generating LR Syntax Error Messages from Examples.” This is what go uses, and OCaml uses a more advanced version of this technique introduced by Francois Pottier in his CC 2016 paper "Reachability and Error Diagnosis in LR(1) Parsers".
Re: Why not to use (f)lex, yacc or bison
#43This is just an advert for ANTLR. I have no real experience with either but the article is really grating to read beyond the introduction.
Re: Why not to use (f)lex, yacc or bison
#44If the new thing is actually better, you should not have to spend the bulk of an article tearing down the old thing to make the new thing look better in comparison.
Re: Why not to use (f)lex, yacc or bison
#45> ANTLR uses an algorithm [...] called ALL. Why is the tool called ANT LR if it uses an LL algorithm? Did earlier versions use LR, or is it just a confusing name?
I think officially it is "ANother Tool for Language Recognition", unofficially it is "Anti LR", which usually is the mindset of ANTLR adherents.
Do they have a reason for this? I have written small LL and LR parsers and the latter seem to make much more sense to me.
Re: Why not to use (f)lex, yacc or bison
#46I tried to read this article, but unfortunately the lack of grammar was too distracting and I just couldn't get through it. A 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 o…
> lack of grammar
lack of "proper" grammar bad grammar
Re: Why not to use (f)lex, yacc or bison
#47Is it not the case that most serious parser implementations are hand-written? In part because it makes it so much easier to provide good diagnostic messages. I feel like every other project moves from parser-generators to hand-rolled parsers and levels.
Also note the amazing architecture behind the Golang template parser/lexer A talk by Rob Like: https://talks.golang.org/2011/lex.slide
- Video of the talk: https://www.youtube.com/watch?v=HxaD_trXwRE
- Grammar documentation: https://golang.org/pkg/text/template/
- Code: https://golang.org/src/text/template/parse/lex.go
Edit: His name is Rob Pike
Re: Why not to use (f)lex, yacc or bison
#48> Can you even imagine the quality of code that was written and fixed for 30 years? Total nonsense. Bison is very reliable, Flex can be a bit finicky to set up but is also reliable. PostgreSQL uses bison ...
Indeed PostgreSQL is a good example of fairly old software (>20 years) that is highly reliable and well used. How many people needing a database complain that they have to have something that has been written, and re-written, in recent years?
Re: Why not to use (f)lex, yacc or bison
#49"ANTLR instead is more actively developed. It has been re-written from scratch a few times during the years, so the code has is of good quality." ... rewrites improve code quality ... right ... right???
Now _I_ can read it, so it _must_ be better!
Re: Why not to use (f)lex, yacc or bison
#50"ANTLR instead is more actively developed. It has been re-written from scratch a few times during the years, so the code has is of good quality." ... rewrites improve code quality ... right ... right???
I first learned Antlr way back about 20 years ago and found it fairly impressive. So when I go to write a new parser or lexer I always go take a look again...
But every time I take a new look at Antlr there's a huge amount of issues related to the fact that they have a huge new rewrite deprecating old versions while the new version is not ready: entirely new ways of doing things with missing documentation and examples, incomplete or missing language backends, and missing packaging for various Linux distributions.
What I get from it is: Antlr is a very powerful project... if you're in the Java ecosystem and if you're willing to use old no longer supported versions.
Otherwise, questionable choice.