C# Parsing – Best Strategy for Writing a CSS Parser

The critical difference between the two approaches is, that the one he considers to be the only correct way is imperative and yours is declarative.

• Your approach explicitly declares rules, i.e. the rules of the grammar are (almost) directly encoded in your code, and the parser library automatically transforms raw input into parsed output, while taking care of state and other things that are hard to handle. Your code is written within one single layer of abstraction, which coincides with the problem domain: parsing. It's reasonable to assume parsec's correctness, which means the only room for error here is, that your grammar definition is wrong. But then again you have fully qualified rule objects and they are easily tested in isolation. Also it might be worth noting, that mature parser libraries ship with one important feature: error reporting. Decent error recovery when parsing went wrong is not trivial. As proof, I invoke PHP's parse error, unexpected T_PAAMAYIM_NEKUDOTAYIM :D

• His approach manipulates strings, explicitly maintains state and lifts up the raw input manually to parsed input. You have to write everything yourself, including error reporting. And when something goes wrong, you are totally lost.

The irony consist in that the correctness of a parser written with your approach is relatively easily proven. In his case, it is almost impossible.

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

C. A. R. Hoare

Your approach is the simpler one. All it precludes is for him to broaden his horizon a bit. The result of his approach will always be convoluted, no matter how broad your horizon.
To be honest, it sounds to me, that the guy is just an ignorant fool, who is suffering from the blub syndrome, arrogant enough to assume you are wrong and yell at you, if he doesn't understand you.

In the end however, the question is: who is going to have to maintain it? If it's you, then it's your call, no matter what anybody says. If it's going to be him, then there's only two possibilities: Find a way to make him understand the parser library or write an imperative parser for him. I suggest you generate it from your parser structure :D

It's not a choice between flex/bison or nothing. There are several options out there. I used antlr for a recent project and found it very nice to work with. Some things you might not have considered:

• Lexers aren't that difficult, but parsers have a considerable number of gotchas you won't even realize until they hit you. Widely used tools have already solved a bunch of problems you don't even know exist yet.
• Your parser will still need to be just as strict as a compiler. The difference will be you can use a simpler grammar in some places, but that will probably be offset by needing to use more complex grammar in other places. For example, code beautifiers often want to preserve an intentional newline that a regular compiler just lumps into "whitespace." If your language has a preprocessor, a beautifier will have to incorporate that into the grammar, whereas a compiler's parser won't.
• Grammars are extremely difficult to debug. Tools like antlr have devoted considerable effort to producing useful error messages. Even if you do go with a custom parser, you may still find it useful to use an existing parser generator to debug your grammar.