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.

parrow. v. to scream repetitively with the force of a runaway wheelbarrow.

fuck off namefag

That fucking answer.

People here have offered much sound advice. My only warning against skipping the parsing tools or just using the Shunting Yard algorithm or a hand rolled recursive decent parser is that little toy languages1 may someday turn into big actual languages with functions (sin, cos, log) and variables, conditions and for loops.

Well, my house might one day need to be a skyscraper, so I bought half a million bricks that I leave lying around just in case. Reminds me of that "you don't want to buy a hammer, you want to buy a hammer factory factory factory" parable about frameworks.

But ShitOverflow always does this. There is always some cunt who doesn't want to answer the question, but wants you to upgrade to Seeples17 and use aa prealpha development version of Boost when all the asker wanted to do was balance a tree or some shit. It gets accepted, becomes the first google result, and all other vaguely related questions get directed to it, leaving the real question unanswered, or hidden at best.

/lounge/

I take offense to this Cudder, please mind the ableism next time (◕‿◕✿)

This is the sort of shit that comes from relying on other people as a source of knowledge.

>>3
Fuck off, imageboarder moron. Being threatened by a name that is seen like once a week is something only a meme loving fuck like you would do. Get the fuck back to /g/ already.

I think Cudder is a pretty cool guy. Eh talks about shit and doesn't afraid of not actually knowing what he's talking about.

>>9
Wow, nice classic meme, ``newfag''!

What programming language is this thread about?
It seems no-one is talking about programming in this thread?
I thought this was a programming discussion board?

>>10
Please stylize your exclamation

>>11
Bison.

>>4
Ironically, even the "big actual languages" don't use parser-generators, because recursive descent is so damn simple and works really, really well. Even Java, a language where you'd probably expect them to have a ParserGeneratorGeneratorGenerator more than anything else, uses recursive-descent. (Full source code for Java's parser here: http://www.docjar.com/html/api/com/sun/tools/javac/parser/JavacParser.java.html - less than 3k lines, it's actually quite good.)

I think you're talking about this article:
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12&

bad thread, stop namefagging

>>14
Take a chill sesh

>>14
bad poster, stop imageboarding

>>16
that's just a non sequiter

>>17
Your argument is at >>8.

You're not fine with just throwing "namefag" imageboard memes? Because "oh but that's a ad homiprojection fallacy" is what a Reddit nigger would do.

>>18
I killed a reddit nigger with my baguette. score one for the good guys

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

toke() every day

>>21
I was expecting that.

>>22
http://cs.uccs.edu/~gsc/pub/phd/ftorres/doc/Compiler.pdf

Any good?

When you don't understand something simple obfuscate it in order to seem smart.

When you don't understand something complex, write something featureless and claim that you're smarter.

When you don't understand something, look it up on stackoverflow to seem ENTERPRISE.

>>24
Haskell.
>>25
Go.
>>26
Python.

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

Yep. well, it's only a page or so of chinese..
Chomsky-Schützenberger hierarchy type 0...

A recursively enumerable language is a formal language for which there exists a Turing machine (or other computable function) that will halt and accept when presented with any string in the language as input but may either halt and reject or loop forever when presented with a string not in the language. Contrast this to recursive languages, which require that the Turing machine halts in all cases.

Sounds like it is a `theoretical' problem

>>28,20
It makes me think parser generators only exist to bridge some sort of mental gap between BNF (from compilers 101, naturally) and actual code. Like other algorithms, do it in C and just follow the steps you would follow to consume a language.

It's all code, guys. Keep it simple.

>>1
go away. ur like all the losers who hang out on ##programming on irc.freenode.net, bitching and whining all day about which programming language is the best. ur too stupid to write anything useful so u bitch and whine on /prog/ about crap that doesn't matter

fuk off and go back to your porn

check 'em

parse these doubles

>>31
this is funny because I've been in there and holy shit these people do not have a lot going on upstairs. Especially ams, that ...thing makes me very sad for it.

Simple custom parsers are generally shit at error reporting. This is one reason parsers are driven by spec instead of hardcoded.

>>35
great point. error reporting is a really difficult problem

>>35
Counterpoint: parsers have to be custom to be able to encode human-useful information on error.
Generated parse error on function(arg1 arg2): ``error at line 1 column 23, `arg2': expected `,' or `)'''
Custom parse error: ``I couldn't understand line 1: Function call arguments need to be separated by commas; try `function(arg1, arg2)' instead (specifically fell over at column 23)''

>>37 has never written a parser. I can tell from having written some parsers myself and from the sheer retardation of her comment.

Come sit on my knee and listen, >>37-chan: you see, the problem when you're parsing a list of function arguments and suddenly encounter "3 + ," is that you encounter the comma when balls deep in the "trying to parse a multiplicand", and at that point you can't say anything more helpful than "I expected a multiplicand or an "(", but got a comma, wtf".

And that's not helpful, my dear >>37. That's not helpful at all, there's not a multiplication operator in sight even, why do you complain about multiplicands? Why are you not helping?

Because to make a helpful error message you got to collect all possibilities from the entire stack trace that got you to that point and weigh them by importance, so that the part where the "+" was expecting something on the right side is more important than what happened deep down below, but also more important than what the "parse a function" expected from that entire list of arguments, or even more so than "parse a program".

And the only way you can do it, my sweet >>37, is by reifying your formal grammar and making a generic parser that can do that figuring out what was expected when a grammar rule failed to apply, and which grammar rule really failed to apply.

*tousles >>37-chan's hair* go play with your legos little one, you are not ready for this.

Wtf why does >>38 never talk to me that way? I hate you >>37, I deserved that treatment more than you.

Muh dik iz big