Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why not to use (f)lex, yacc or bison

tomassetti.me

Post reply on HN
Print view View original

11–20 of 91 posts

Re: Why not to use (f)lex, yacc or bison

#11

Post by xalqpp »

skrebbel wrote: post #4

Last 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.

No, you can use the reentrant interface, flex can handle that:

https://www.gnu.org/software/bison/manual/html_node/Pure-Cal...

Re: Why not to use (f)lex, yacc or bison

#12

Post by someone13 »

skrebbel wrote: post #4

Last 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.

See Lemon, which generates re-entrant and threadsafe parsers and is used in SQLite: https://www.hwaci.com/sw/lemon/

Re: Why not to use (f)lex, yacc or bison

#13

Post by mlyle »

skrebbel wrote: post #4

Last 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.

Both flex / bison can deal with reentrancy. Granted this is relatively new as far as flex & bison goes-- the functionality was introduced in mid-2001.

Re: Why not to use (f)lex, yacc or bison

#16

Post by mhd »

It's been a while, but I had some fun using the "lemon" parser generator[1] used by SQLite. Worked alright for something where regexes weren't enough and I couldn't be bothered to write a custom parser. Probably has the same cons that lex/yacc would get, according to the post.

I do have the ANTLR book, but to be honest, if I would have the task of doing something more involved and where integration isn't as important (i.e. it could be an isolated command, not a module for huge Java/C# app), I'd probably be more inclined to get deeper into SML/Ocaml than ANTLR for this.

[1]: https://www.hwaci.com/sw/lemon/

Re: Why not to use (f)lex, yacc or bison

#17

Post by kqr »

Is 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

#18

Post by xalqpp »

pansa2 wrote: post #15

> 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.

Re: Why not to use (f)lex, yacc or bison

#19

Post by spider-mario »

kyeb wrote: post #9

I 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…

> the lack of grammar

How ironic, right?

Re: Why not to use (f)lex, yacc or bison

#20

Post by akdor1154 »

I have used ANTLR to write a parser for a simple language and found it kind of confusing, but put it down to being new to ANTLR and to parser generators in general. The reason I chose it was for its ability to output parsers in multiple implementation languages for a single grammar - lemon et al seem to be tied to C. Are there any other systems the HN crowd would recommend for this use case?
Post reply on HN