On Jul 5, 2011, at 10:45 PM, Brendan Eich wrote: > On Jul 5, 2011, at 10:35 PM, Brendan Eich wrote: > >> On Jul 5, 2011, at 9:00 PM, David Herman wrote: >> >>> Mainstream production JS engines have moved away from parser generators. >> >> Right, indeed most (all but JavaScriptCore, IINM) never used a parser >> generator in the first place. A great many industrial language >> implementations do not use generated parsers. > > Some of the reasons for this include > > * Hand-crafted parsers can be significantly faster than Bison or the like. > Yes, I'm generalizing.
In our case 2-3x, when going from bison to hand coded > * Lack of parameterized productions (e.g. for "NoIn" vs. unsuffixed ECMA-262 > nonterminals) requires significant duplication of sub-grammar productions and > their semantic actions. Yup -- absence of mode switches in generators is poor. > * Error recovery is usually better in hand-crafted parsers. Can't speak for error recovery (JSC's parser makes no attempt to recover after an error), but you can produce much more useful error messages than most generated parsers allow. > Oliver may have more to say -- he got rid of JavaScriptCore's Bison grammar, > which dates back to KJS. There are a few other advantages, mostly relating to controlling stack usage and minor tweaks like branch ordering. One issue I had looking at parser generators is that they all tend to either want a large library brought in (ANTLR) or specific (ugly) member names in the types that you provide (entire YACC family). Also they have a tendency to assume trusted content -- ANTLR will happily overflow the stack, which is clearly not ideal. --Oliver > > /be > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
