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.

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

>>37

I couldn't understand line 1:

What the fuck do you think this is, r/programming?

>>37
I agree with >>38, but >>38-sama forgot to also mention that you're a shit-fucking cuntstain who should strangle yourself with your dad's pubes and never touch a keyboard again.

>>38
Bullshit. Generated parsers have horrible errorhandling, so much that you often need to add additional rules just to do it. Nothing quite as simple as RD where you just put the code in the right place. This was one of the main reasons GCC moved to RD from a Bison parser.

But in any case, "X was unexpected here" is usually enough of a clue to the programmer what's wrong.

>>43
fuck off namefag

/prog/ challenge: write an expression parser with precedence

>>40
Thanks

>>38
The only tractable way to generate meaningful error messages giving suggested fixes in a non-accusatory tone (I EXPECTED A CLOSING BRACE HERE YOU FUCKING MEATBAG) is to special-case them. By definition you cannot do that generically.
_{By the way, it makes me hot when you do that.}

>>41
A programming languages is a UI too. Treat your users nicely. It's no longer 1989. There's room in your program for a little internal documentation.

I was thinking about these pages, but turns out they're about semantic errors rather than syntactic errors. It's still worth caring about this stuff though.
http://elm-lang.org/blog/compiler-errors-for-humans
http://elm-lang.org/blog/compilers-as-assistants

>>47

The only tractable way to generate meaningful error messages giving suggested fixes in a non-accusatory tone (I EXPECTED A CLOSING BRACE HERE YOU FUCKING MEATBAG) is to special-case them. By definition you cannot do that generically.

At the very least you can collect _all_ things you could have expected, annotated with human-readable production names and sorted by priority (for example the rule that just consumed a terminal like "+" should be given priority).

Of course you could be doing that in your recursive descent parser too, in an ad-hoc, verbose, and awkward manner. I'm not sure I'd describe it as "tractable".

>>49
Fuck all the way off.

>>49

you could be doing that in your recursive descent parser too, in an ad-hoc, verbose, and awkward manner.

You mean with a single extra parameter context[] for each rule? Yeah, so awkward.

>>51
That would make compilation SLOW AS BALLS though. Not that it's a bad thing, I'm all for it, though tt might not be feasible in those cases where it actually is the most useful, like compiling a big ``low-level'' language (which might be hard to debug) on a slow embedded device.

>>52
Would it? Evidence? I'm going to go out on a limb and say that an additional, explicit stack won't add much overhead.

>>52
The fastest C compiler I know of is TCC. Recursive-descent parser. You're wrong.

>>54
faggot
also dubs

>>54
What actually makes TCC so fast? GCC is recursive-descent too, isn't it? Yet GCC is a lot slower.

>>1
there's a big difference between knowing how to do something and knowing when it's a waste of time.

plenty of compilers you aren't even aware of don't use a hand-written parser, though they may use recursive-descent.

>>56
likely has more to do with the optimizations that gcc does, rather than parsing

>>43

i have never used a proper parser generator

nice one bro

>>52

doing this thing by hand would make it slower that doing it automatically via parser generator

>>56
TCC doesn't optimize much, it has minimal functionality that mimics GCC.

>>56
Because GCC was written by a bunch of GNUtarded academics more interested in the philosophy of software licenses than anything else. RMS wanted to make GCC so convoluted that no one would attempt to modify or extend it, and that's the result. It's not quite enterprisey, but it's a similar attitude that creates other things like their 50-line+ true and false.

It also parses a bunch of other C-ish languages (like C++) in the same code so there are plenty of conditional branches that would always go one way or the other, but the bloat is still there.

>>60
GCC -O0 is still much slower than TCC.

C-dder is all talk and no action.

Cudder is all talk, and even his talk is shit.

>>63

his

WELL FUCK ME IN MY DICKHOLE WITH YOUR 6-INCH CLIT

_{(this space left intentionally androgynous)}

Check em

stop being a namefag

>>68
No u

>>69
clock quads