Idiots don't know how to parse...

http://stackoverflow.com/questions/28256/equation-expression-parser-with-precedence

WTF? The accepted answer is from someone who thinks recursive descent is "hard" and a ridiculously bloated parser-generator is "easy"? Pure bisonshit! Almost every real (and toy) compiler uses some variant of recursive-descent. Even GCC, which would probably be the biggest user of Bison, moved to recursive-descent years ago.

These aren't even programmers, these are Java-sipping codemonkeys who know next to nothing about how anything really works and can only parrow "reinventing the wheel" and other "enterprise best practices" bullshit.

It's as easy as this:

AST *expr(int level) {
AST *v = atom();
while(tprec >= level) {
int op = token, prec = tprec;
toke();
v = AST_new_binop(op, v, expr(prec + 1));
}
return v;
}

Just add a tokeniser, AST-creator, atom() (unary handler), and operator table, and you'll have a perfectly working, tiny and easily extensible expression parser. I've written a C expression evaluator with this at its core, supporting all the standard C operators and their dozen levels of precedence. I wasn't even aiming for small size, and yet the whole thing is < 300 LoC including comments. The binary is a little below 4KB but that's probably just due to C's inherent bloat. Maybe I'll rewrite in Asm and make it 1/4 of that, because that core function itself should be a few dozen bytes at most.

Messing around with YUCC and Bishit will waste more of your time.

Next up, a full C parser...

>>23
I was expecting a PhD thesis, instead I got a crappy Chinese version of the Dragon Book? Most of that 30MB is useless though, as all you need is a FSM tokeniser and recursive-descent parser. The rest is academic wank.

Proof? The grammar of C++ is known to be Turing-complete. According to the academics, it's Chomsky type 0. Yet working C++ compilers obviously exist, and almost every practical one uses a recursive-descent parser.

Don't even get me started on the "dangling else problem", which is NOT AT ALL A PROBLEM but an artificial one created by the circlejerking academics...

if(token == TOKE_IF) {
toke();
expect('(');
expr();
expect(')');
stmt();
/* THIS IS THE SOLUTION - FOUR LINES OF CODE */
if(token == TOKE_ELSE) {
toke();
stmt();
}
}

Check for an 'else' after 'if', if there is one then obviously consume it and the associated statement. Nothing could be simpler. Why do those idiots think it's hard and have to spend innumerable amounts of time convincing others that it's a problem? It's not. It only becomes one if you want to associate elses with outermost ifs, which no programming language I know does because it makes no sense.