General disclaimer:

We’re considering restructuring this code in the near future and can’t guarantee that your work will be compatible with future versions.

1. The Parser does not know about block statements. Is there a reason for that?

     None that I'm aware of. I agree, a block node is a good idea. Even if the semantics of a statement-list are exactly the same, we can't recover the      original source once this simplification occurs.

2. let statement.

     I'm not sure about the future of the let statement given ECMA "Harmony".

3. Overriding Parser methods.

     I disagree. It would be better for reusability and stability if the Parser/Scanner module's sole function was to verify syntax

     and produce an AST. Given future requirements for compile performance, we may need several parsing solutions.

4. Multiple context classes and global scope confusion.

     I agree. I'm looking at some of this code now. It's unnecessarily complex.

5. What is the general strategy one has to follow in order to compile?

     Refer to CompilerAPI.java. There's a general workflow model defined there.

6. Is there another way to get to the AST?

     If you're interested in a single AST (per file) I think your approach is reasonable. By invoking an instance of the Asc parser directly, you've simplified significantly. However, you could pick up the AST form at later compile stages, which might have completed some transformations and semantic analysis that would be of some use to you. Most code referring to the AST uses some derivation of the Evaluator pattern.

Having Asc parser internal methods private allows us to improve it more safely. The existing node form may be simplified as well, which is a major overhaul.  If you're considering a feature of general usefulness we might be able to incorporate it as part of ongoing development, else your probably better off branching, since it'll break anyway.

Detection of const declarations within loop constructs:

I'd add the warning at a lint level, since without some dynamic programming (or known tripcount) even flow analysis wont tell you that the loop is intended to execute only once (which would be legal).

Class constructor invocation order:

I think the real question is, "When do package global statements get executed?".

--I'll get back to you on this one.

I think i want to do the same thing.  I was an AST in xml form.

I have a different approach though.

I am using the asdoc tool and am using the keep xml option.  I am then adding methods to the *Node classes that return sensible structures.  These are being called in the TopLevelGenerator class.

I am worried that i am adding code to classes that are likely to change with future versions.  Is there anything else i can do? Is this a good approach?

TIA

Eamonn

One of the areas currently under development in the Asc Parser is the Node class and the shape of the AST built.

One of the existing Node visitor patterns is likely adaptable for your current purposes.

.

Again, the existing Node classes are subject to change in the very near future and  I can almost guarantee that any work

based on the current intermediate representation will be incompatible with ongoing work

It'd be fun to have a lot of people working on the compiler. First we need to get some basic components down to simpler representations.

The Node class and the way ast's get built and used can be much improved, we're working on that now. It's so fundamental it's hard to start parallel efforts until that is complete. We're hoping to start defining a clearer roadmap within the next few weeks.