JavaScript parser API

Oliver Hunt oliver at apple.com
Wed Jul 6 10:13:34 PDT 2011


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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list