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
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
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
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日周日
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
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
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
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
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:
>
9 matches
Mail list logo