(And, really, returning something of type “Any”?)
Why not to use (f)lex, yacc or bison
21–30 of 91 posts
Re: Why not to use (f)lex, yacc or bison
#22Is 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.
Re: Why not to use (f)lex, yacc or bison
#23Is 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.
[0] https://github.com/apache/spark/blob/master/sql/catalyst/src...
[1] https://github.com/prestodb/presto/blob/master/presto-parser...
[2] https://github.com/microsoft/TypeScript/blob/master/src/comp...
Re: Why not to use (f)lex, yacc or bison
#24Re: Why not to use (f)lex, yacc or bison
#25Is 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.
This is actually pretty true based upon what I've personally observed too. While Apache Spark [0] and Presto [1] use ANTLR to implement their parsers, when I searched about TypeScript's parser and noticed that they implement their own parser [2] (in TypeScript itself), the reason I was able to find was that the nuanced error messages which a language like TypeScript has to provide is only feasible by hand-writing the…
I wonder if this is relevant to how bad the error messages generally are in Typescript.
Re: Why not to use (f)lex, yacc or bison
#26Re: Why not to use (f)lex, yacc or bison
#27Is 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.
Re: Why not to use (f)lex, yacc or bison
#28Maybe 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
#29Is 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.
For general-purpose languages, yes, but there are some exceptions. Ruby uses yacc, and Python uses a custom LL(1)-ish parser generator, which is in the process of being replaced by a custom PEG parser generator [0]. [0] https://github.com/gvanrossum/pegen
Re: Why not to use (f)lex, yacc or bison
#30Last 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.