Breton Slivka wrote: > On Tue, Dec 8, 2009 at 3:57 PM, David-Sarah Hopwood > <david-sa...@jacaranda.org> wrote: > <snip> >> That would however depend on an assessment of whether browser >> implementors had succeeded in implementing secure and correct >> ES5->AST parsers (with a mode that accepts exactly ES5 as specified, >> not ES5 plus undocumented cruft and short-cuts for edge cases). > > would it make sense to abandon our attachment to using the browser > native parser, and just implement an ES5 parser/serializer as a > seperate standard unit, without ties to the js engine itself? Would > there be significant disadvantage to having two parsers in one ES > interpreter?
What "attachment to using the browser native parser"? It's an implementation detail how the ES5->AST parser is constructed. However, I wouldn't expect many implementors to want to duplicate code and effort. Note that with an event-driven parser, for example, it's trivially easy to plug in different event consumers to the same parser and generate different AST formats. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
