I keep asking myself whether building yet another parser generator is worthwhile, especially since it's slowing me down. So far the answer remains "yes". Here are my reasons:
1. There are no parser generators that emit BitC, and none that can *easily* be modified to do so. Yes, I *do* know about Antlr. 2. From a specification perspective, writing a EBNF grammar for the language is insufficient, because it fails to specify the parse algorithm. Given a full EBNF for C++, you still don't know enough to parse it. 3. I want the tool to keep me honest about not introducing *ad hoc* parse rules and/or parse ambiguities. 4. While other algorithms provide more powerful recognizers, LL(k) parsers are the easiest ones to do error reporting for, and error reporting is important. More power is not always better in practice. 5. For other uses - notably IDEs - it's important to be able to generate bottom-up partial parsers. Once again we want a solid specification of the grammar. 6. I don't know of any grammar tool that can generate LL(k) and LR(k) parsers from a common grammar specification. This is mainly because of the left recursion vs. right recursion issue, and a couple of nullification details. It's not hard to build a syntax for grammar specifications that can go both ways. Mainly, it's that I *really* want an unambiguous specification. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
