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 `.foo { display: block; color: red; }` as `.foo {
display: block; } .foo { color: red }` with a cached selector (which
*would* be easier to process later on). In this case, they're
basically just exposing the same parsers they'd have to use in
practice anyways, so it's literally trivial for them to add.
2. No JS engine parses nodes the way the spec processes them, just in
a way it's unobservable mod timings. They internally parse `1` and
`1.0` as different types, and they will do things like constant
propagation - `3 * 5` gets parsed as `15` usually, and `"a" + "b"`
will usually get read as `"ab"` by some engines. Furthermore, browser
engines lazily parse functions where they can, only validating them
for early errors and storing the source code to reparse them on first
call, because it helps them start up faster with less memory. And of
course, `typeof value === "string"` is often not simply compiled to
`%IsString(value)` but literally parsed as such if `value` is defined
in that scope. And finally, engines typically merge the steps of AST
generation and scope detection, not only to detect `let`/`const`
errors but also to speed up bytecode generation.
So although it sounds like JS engines could reuse their logic, they
really couldn't. This is further evidenced by SpiderMonkey's parser
API (the predecessor to the ESTree spec) not sharing the same
implementation as the core language parser. There's two vastly
different concerns between generating an AST for tooling and
generating an AST to execute. In the former, you want as much info as
possible readily available. In the latter, you just want to have the
bare minimum to compile to bytecode with relevant source locations for
stack traces, and anything else is literally just unnecessary
overhead.
-----
Isiah Meadows
[email protected]
www.isiahmeadows.com
On Sat, Sep 14, 2019 at 9:41 AM Gareth Heyes
<[email protected]> wrote:
>
> 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
> http://businessinfo.co.uk/labs/MentalJS/MentalJS.html
>
> It would be great to have a parser in JS!
>
> On 14 Sep 2019, at 06:46, Jack Works <[email protected]> wrote:
>
> 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
> details (and also, finding champions!)
>
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
