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

41–50 of 59 posts

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

#41

Post by mateo411 »

1vuio0pswjnm7 wrote: post #36
mateo411 wrote: post #31

Earlier quoted context omitted.

The input changing shouldn't matter. Maybe you could see a performance issue if you had to parse a really large file/files. The issue would be if the grammar to what you are parsing changes. If that changes, then no parser will work, correctly until it supports the new grammar. As a practical matter the grammar can act like a contract between the two systems. You don't have control of the input, but the input must fo…

Does the separation of the grammar into its own file, like a .y file for yacc, make it easier to modify the grammar at a later point. Similarly, is it easier to modify a parser later on, if the input changes, if the patterns to be searched in the input and the state machine are stored in a separate file, like an .l file for flex.

I would think so.

I don't work on parsers and grammar day to day, so I might not be the best person to ask about this. I am interested in the subject though. I just don't get to work on this in my current day job.

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

#42

Post by AshamedCaptain »

karmakaze wrote: post #39
ksaj wrote: post #18

Earlier quoted context omitted.

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.

Antlr and LL(k) parsers in general are great when they fit the grammar you want to make well. I remember discovering it when it was called JavaCC a nod to yacc.

Heh. at my grad school we had a pccts fan (antlr before java even existed) and he actually tried to paint the LR vs LL war as a american vs european thing (this was in france).

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

#43

Post by bear8642 »

pengwing wrote: post #21

It's 2021, why not use parsing expression grammar?

perhaps because you want LALR or other techniques?

Can't remember why but my Compilers teacher (Adrian Johnstone, Royal Holloway) doesn't like PEGs - think due to parse forest not being generated?

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

#44

Post by abss »

For c/c++ just use lemon: https://en.m.wikipedia.org/wiki/Lemon_(parser_generator)

I think that lemon is comming from the same author as sqlite. I used it like 15 years ago ;) but i still remember lemon as high quality piece of software (Much better compared with flex, yacc, bison...)

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

#45

Post by yjftsjthsd-h »

robocat wrote: post #33
WesolyKubeczek wrote: post #19

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

I am guessing that the author is referencing organisations that are pathologically allergic to GPL, where the legal department might not accept the exception. https://www.google.com/search?q=bison+gpl+exception

"Incompetent legal dept" is not a bug in the product.

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

#46

Post by mbrodersen »

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?

Both ANTLR and Yacc are painful to work with. I ended up writing my own parser generator instead. So much better!

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

#47

Post by mbrodersen »

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…

Yep same here. It is really easy to write parsers by hand if you know what you are doing.

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

#48

Post by mbrodersen »

1vuio0pswjnm7 wrote: post #24
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.

It is super easy to change. It is just normal code.

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

#50

Post by jgwil2 »

mbrodersen wrote: post #46
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?

Both ANTLR and Yacc are painful to work with. I ended up writing my own parser generator instead. So much better!

Is it open source?
Post reply on HN