Happy to see standard ast in binary ast proposal. For compiler, it can have a "slow" mode when parsing with this parser API and still use fast code generation in other cases. But unfortunately it seems there are much more work than I think to provide such an API.
David Teller <dtel...@mozilla.com> 于 2019年9月15日周日 下午7:02写道： > Before you can have a standard parser, you need a standard AST. There is > no such thing as the moment, so the v8 parser, the SpiderMonkey parser > and the JSCore parser, etc. all use distinct internal ASTs, each of > which changes every so often, either because the language changes or > because the VM needs to attach different information to help with > compilation. > > That's the main reason for which there hasn't been a standard > user-accessible ECMAScript parser in ECMAScript. > > As Binary AST relies upon having a standard AST, standandardizing the > AST is part of the Binary AST proposal. You may find the latest version > of this AST online > https://github.com/binast/binjs-ref/blob/master/spec/es6.webidl > > Cheers, > David > > On 14/09/2019 10:10, Jack Works wrote: > > This proposal is not a part of the binary AST proposal. Because that > > proposal wants a binary representation and will not generate AST > > directly from the ecmascript spec. > > Because run those parsers in browser is pretty slow. Since the JS engine > > can already parse the JavaScript code, just expose those interfaces will > > make things easier. > > > > > > Out of curiosity, what is the expected benefit wrt Esprima, Babel or > > Shift? In particular since there is no standard AST for ECMAScript > > yet [1]? > > > > Cheers, > > David > > > > [1] Ok, that's a subset of > https://github.com/tc39/proposal-binary-ast, > > which is in the pipes. > > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
