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

Why you should not use (f)lex, yacc and bison

tomassetti.me

Post reply on HN
Print view View original

21–30 of 59 posts

Re: Why you should not use (f)lex, yacc and bison

#22

Post by [deleted] »

ksaj wrote: post #18
AshamedCaptain wrote: post #7

Glad to hear the ANTLR vs Yacc holy way (a.k.a. LL vs LR) is still going strong. This one holy war may actually be older than emacs vs vi. Have the ANTLR guys dropped their Java credo or they're still thinking they are going to convince any C developer with a .jar?

This is actually the first time I've even heard of ANTLR, which came about in the early 90's. But yacc/lex/vi/emacs, et al have been around since the 70's. The emacs vs. vi holy war was pretty much instant, but doomed every time one spoke of headless devices such as routers.

[deleted]

Re: Why you should not use (f)lex, yacc and bison

#23

Post by lallysingh »

atomicnumber3 wrote: post #9

I used ANTLR to build a query language parser and interpreter for a past employer. They had a specialized use case. ANTLR was pretty pleasant to use. The solution ended up being a pretty small amount of code and enabled much more powerful searching in their internal data viewing tool. I still think fondly about the project from time to time, partly because it was the one project where my fellow devs were just as happ…

The IDE and tree parser modes are pretty nice!

Re: Why you should not use (f)lex, yacc and bison

#24

Post by 1vuio0pswjnm7 »

stephc_int13 wrote: post #6

I learned about the existence of Lex, Yacc, and Bison a bit more than 20 years while discussing the difficulties of debugging handwritten parsers with a friend. But I was quickly discouraged by the complexity of using these tools, they are more like a new language that you have to learn. Today I prefer writing parsers by hand, in C, like Fabrice Bellard, it is not super easy but manageable and I never encountered maj…

How easy is it to make quick changes to hand-written parsers.

Imagine, for example, that the input being parsed is not under the authors control and it suddenly changes. The parser must be changed.

Re: Why you should not use (f)lex, yacc and bison

#26

Post by eqvinox »

A quick search for "reentrant flex bison" gets me this:

https://stanislaw.github.io/2016/03/29/reentrant-parser-usin...

which in turn links this:

https://github.com/blynn/symple/tree/75aaea79141a18a234c94dc...

The magic flags are:

  %option reentrant
and

  %lex-param   { yyscan_t scanner }
  %parse-param { yyscan_t scanner }
  %parse-param { val_callback_t callback }
... so ... it seems a reentrant flex/bison parser is easily possible?

Re: Why you should not use (f)lex, yacc and bison

#27

Post by dmitrygr »

truenindb wrote: post #17
dmitrygr wrote: post #13

This reads more like an ad for ANTLR than a criticism of flex&bison. Very few criticisms are offered, and most of them are quite handwavy.

The re-entrancy complaint seems legit if actually well founded, although I'd think that it probably says somewhere in Flex/bison docs that the generated parsers expect only to be entered from a single C process. It sounds to me like they were using Flex/Bison generated parsers inside of some huge messy corporate web codebase, probably for webscraping or some kind of semi-structured data cleaning, and the code clammed…

flex & bison use globals to report things per-rule. Of course they are not re-entrant. This is documented by virtue that those are globals.

Re: Why you should not use (f)lex, yacc and bison

#28

Post by dilap »

stephc_int13 wrote: post #6

I learned about the existence of Lex, Yacc, and Bison a bit more than 20 years while discussing the difficulties of debugging handwritten parsers with a friend. But I was quickly discouraged by the complexity of using these tools, they are more like a new language that you have to learn. Today I prefer writing parsers by hand, in C, like Fabrice Bellard, it is not super easy but manageable and I never encountered maj…

Same experience here; recursive descent parser advantages:

- It's just normal code; you don't have to go learn a whole 'nother thing

- Easy and fun to write (ymmv)

- Does not add extra dependencies to your build system (the time I've wasted getting the right version of yacc installed just to handle software that parses some trivial grammar...)

- You can easily deliver really good error messages to your users (they love this!)

Disadvantages:

If you're not careful, you can accidentally end up w/ some sort of weird frankenstein grammar

Re: Why you should not use (f)lex, yacc and bison

#29

Post by eqvinox »

dmitrygr wrote: post #27
truenindb wrote: post #17

Earlier quoted context omitted.

The re-entrancy complaint seems legit if actually well founded, although I'd think that it probably says somewhere in Flex/bison docs that the generated parsers expect only to be entered from a single C process. It sounds to me like they were using Flex/Bison generated parsers inside of some huge messy corporate web codebase, probably for webscraping or some kind of semi-structured data cleaning, and the code clammed…

flex & bison use globals to report things per-rule. Of course they are not re-entrant. This is documented by virtue that those are globals.

And the fix is to not use globals. cf. my toplevel post about "%option reentrant", "%lex-param" and "%parse-param".

Globals are just the 80's setup, and flex/bison are supposed to be POSIX lex/yacc compatible, so I'm gonna count this as "shitty defaults due to compatibility with stone tablets".

Post reply on HN