Amazing work Sundar. I can see this being a very strong point for Nashorn for 
people writing tools that work with JS source files.

Two typos:
   - JSONWriter: assert "should reach here" should read "should not reach here"
   - withcheck.js: typo: "diganostic"

I'm also very happy that we have synthetic marker on BlockStatement. That's 
actually something that we could now use for more precise let/const scoping. I 
think though that we should add the flag on Block, not on BlockStatement. Block 
already has a flags bitfield, BTW, but that's not the reason. The reason is 
that we're historically introducing synthetic blocks elsewhere too. "if(...) 
stmt;" becomes "if(...) { stmt; }" internally as our AST is structured so that 
IfNode, ForNode, WhileNode, CaseNode etc. do not hold Statement nodes as their 
bodies, but Block nodes instead. This is strictly speaking incorrect mapping of 
the ES grammar, but I guess that for now we're stuck with it.

Those blocks are synthetic too, and we aren't distinguishing them on the AST 
level from explicit blocks present in the source code. It isn't much of a 
trouble for contexts where only a single statement can be specified without a 
block (which is most contexts in JS) but it can be a trouble for switch/case, 
as "case x: stmt1; stmt2; case y: ..." and "case x: { stmt1; stmt2; } case y: 
..." have differing semantics in ES6 if stmt1 is a let/const. So I think that 
if we're finally adding a "synthetic" flag (as we should!) to blocks, it should 
be marked on Block, not BlockStatement.

Attila.

On Mar 9, 2015, at 7:02 AM, A. Sundararajan 
<[email protected]> wrote:

> Please review "Nashorn Parser API". Introduces jdk.nashorn.api.tree package 
> to support parser API for Nashorn.
> 
> JEP: http://openjdk.java.net/jeps/236
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074671
> Webrev: http://cr.openjdk.java.net/~sundar/8074671/
> 
> Simple examples "evalcheck.js" and "withcheck.js" under samples directory 
> added.
> 
> Thanks to Joe Darcy who helped me with extensive specification review.
> 
> Thanks,
> -Sundar

Reply via email to