| > > http://gcc.gnu.org/gcc-4.1/changes.html | > > | > > New Languages and Language specific improvements | > > C and Objective-C | > > | > > * The old Bison-based C and Objective-C parser has been replaced | > > by a new, faster hand-written recursive-descent parser. | > | > Hahahahaha, WRONG!!!!!! | > It's one historical error of many years of stupid engineers, developers, | > programmers and boss!!!!! | | OK, we are all stupid, and you think that you are smart.
It was a nice JOKE!!! I'm stupid too ;D | > "Hand-written recursive-descent parser" == LL(k) | > however, people does it as LL(1). | > | > The grammar of Pascal language can be LL(1), but the grammar of | > C, C++ and Objective-C together won't can be LL(1). | | But yet gcc 3.4 has a hand-written recursive descent parser for C++. How | can this be? The answer, of course, is that it is not LL(1). OK. | > However, they together can be LALR(1) (or impossible in worst-case) from | > Yacc/Bison. | | Make that "impossible". C++ is not LALR(1), and in fact it requires | unbounded lookahead. Back when we had a Bison parser for C++, it was | made to work by putting another pass between the lexer and the parser to | look ahead far enough to disambiguate some of the nasty cases. However, | there were many corners of the language that it could not parse correctly. | That's why we replaced it. Do you demonstrate that "C++ is not LALR(1)"? | > Writing Hand-written recursive-descent parser miss-cleans the source code | > and goes hardfully to maintain it!!! | | Not if you know how to write one correctly. However, they are many KLOCs in .c compared to few KLOCs in .y (glossary: KLOCs = Kilo Lines of Code) | > The best option is a clean grammar in Yacc/Bison!. | | GCC had such parsers for over a decade, and yet they are being replaced. | | Bison remains a good solution in many cases, especially for languages | specifically designed to be easy to parse with an LALR parser (that is, | languages that don't look like C). Why don't we develop a "LR(k) / k small" functions-written parser for this complex grammar?
