Hand-written rec-descent parser of GCC-4.1 is WRONG!!!

[jc-nospam@jr-pizarro.jazztel.es]

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