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

11–20 of 59 posts

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

#11

Post by criddell »

mcguire wrote: post #4
PaulHoule wrote: post #2

I would have upvoted this article except for the fact that it popped up not one but two pop-up windows asking for my email address.

Both of which were ads for ANTLR services, which is what they provide.

On other articles (like this [1]), they put a box at the bottom where you can submit your email address. It's far more respectful way to do it.

[1]: https://tomassetti.me/working-with-excel-in-python/

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

#12

Post by quickthrower2 »

legulere wrote: post #8

If you push out enough grammars that makes writing lexers and parsers by hand more work than learning tools for that, you will soon have all kinds of other problems.

The piece is written by a consulting company who by design are probably pushing out a lot of grammars but to different systems and companies.

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

#15

Post by truenindb »

Okay, so yes it is good to note that the GNU lexical generator toolkit does not generate unicode parsers and isn't re-entrant. In general, parsing the same text from multiple threads seems like it could probably lead to more problems than just the fact that the parser generator toolkit for compiler writers isn't re-entrant, but that sounds more like a problem for the 'design' of these folk's client's codebases than anything else to me. It would be nice to see a simple LL(1) lexer/parser generator in C that handles unicode and re-entrancy, although again, the latter one seems like something of a complex concept to me. Having the library generate parsers which are stable across multiple threads using generated parsers to parse different things at once seems like the only stable notion that I'd care about, so I will assume that is what this fellow is talking about.

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

#17

Post by truenindb »

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 up in some way.

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

#18

Post by ksaj »

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.

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

#19

Post by WesolyKubeczek »

> flex uses a BSD license, while Bison uses the GPL. Bison waive the license for most generated parsers, but it can be a problem

Now, this is one of the most atrocious handwavy kind of FUD that I've had a displeasure to see. If the parsers generated by bison are GPL-free, where is the problem? Can you even name the problem? Or you just see the word "GPL" and it's scaring you somehow?

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

#20

Post by lallysingh »

truenindb wrote: post #15

Okay, so yes it is good to note that the GNU lexical generator toolkit does not generate unicode parsers and isn't re-entrant. In general, parsing the same text from multiple threads seems like it could probably lead to more problems than just the fact that the parser generator toolkit for compiler writers isn't re-entrant, but that sounds more like a problem for the 'design' of these folk's client's codebases than a…

Consider any server side query system. Parsing those queries in only one thread can be prohibitive.
Post reply on HN