So I'm building a new parser, and staring at the Boost Spirit library. I'd like some input.
There's a lot to learn here, of course, but the main issues that concern me are (a) compile time for a larger grammar and (b) error checking and recovery. I'm still working through the boost docs on the latter. For calibration, the *original* bitc parser had 303 productions involving 131 non-terminals. Some of that will simplify, but most of it probably won't. Because of the layout rules, the original parser also involved some seriously *sleazy* tampering with the lexer, the lookahead mechanism, and error processing. See here<http://dev.eros-os.com/hg/bitc/file/ee6c3b5da8da/src/compiler/TransitionParser.y#l2694>for an example. Basically, there were cases where the easiest way to implement the layout rules was by making syntax-directed corrections from the parser. The OptRCB is a case in point. That gets used whenever we syntactically require a right curly-brace that may not have been provided by the user. If we fail to get it, we forge one, and then push the current lookahead token back onto the lexer and clear the lookahead state so that we will re-fetch the token. This can only be characterized as an unclean hack. I have no idea if a comparable hack is feasible - or even necessary - in Spirit. Yacc is a non-backtracking parser. For various reasons I didn't want to go to a full GLR parser. Given the general challenges inherent in compiling templates, part of me is terrified at the prospect of templates that turn into a single file having 303 procedures, but the reality is that yacc/bison emit approximately the same amount of junk. I have two concerns about error checking. The first is generic: error recovery while parsing is hard with *any* parser generator. The second is that Spirit doesn't detect parse conflicts because it doesn't really check the input (or at least, not beyond checking agreement for template expansion purposes). There have been a couple of conflicts of this form during the design of BitC where resolving them was a serious pain, and I was *very* happy to have the support of a parser generator that checked the grammar for conflicts. So: any advice from people who have actual experience with boost::spirit? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
