Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

Nit: Acorn's *output* is based on Esprima. Its code is *not* and hasn't been for a few years now. It started a fork of Esprima, but it wasn't long before it was rewritten the first time. - Isiah Meadows cont...@isiahmeadows.com www.isiahmeadows.com On Mon, Sep 16, 2019 at 1:58 AM kai zhu

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

adding datapoint on application in code-coverage. a builtin parser-api would be ideal (and appreciate the insight on implementation difficulties). lacking that, the next best alternative i've found is acorn (based on esprima), available as a single, embedabble file runnable in browser: ```shell

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

In theory, it should be possible to have both modes, if the parser is designed for it. Unfortunately, that's not the case at the moment. Mozilla has recently started working on a new parser which could be used both by VMs and by JS/wasm devs. It might help towards this issue, but it's still early

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

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 于 2019年9月15日周日

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

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

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

I do want to note a couple things here, as someone familiar with the implementation aspect of JS and programming languages in general: 1. The HTML and CSS parsers (for inline style sheets) have to build a full DOM trees for each anyways just to conform to spec, so they can't just, say, parse

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

I had a few goes with making a JS sandbox. I also created a safe DOM environment that allowed safe manipulation of innerHTML etc JS sandbox with regular expressions http://www.businessinfo.co.uk/labs/jsreg/jsreg.html JS sandbox and safe DOM environment

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

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

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

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. On 14/09/2019 07:46, Jack Works wrote: >

A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

Just like DOMParser in HTML and Houdini's parser API in CSS , a built-in parser for ECMAScript itself is quite useful in many ways. Check out https://github.com/Jack-Works/proposal-ecmascript-parser for