Hi Yuriy, The why is easy: I couldn't make sense of the deeply nested arrays that were present in the parts of the parsed code that weren't modeled in the existing AST, so I tried to make a model that I could have a chance of navigating. As to the nodes themselves: - some of them were already there, and I just hooked them up to the parsers. - some I would claim aren't strange (such as the ForStatementNode),and probably don't deserve the label 'strange'. - several really do deserve the label 'strange', though. These were ones where I wasn't sure what was being parsed out, and just blindly followed the parser naming convention. This is where the odd/strange nodes like PrimaryWithSelector came from. That one, at least, has been removed with a better set of nodes to replace it (MethodInvocationNode and VariableAccessorNode). The rest have not been rethought to make their usage clearer. Going forward, I plan on removing some of the nodes (PJArguments and PJTypeArguments should just be an array in the containing node; PJThisIdentifierNode and PJSuperIdentifierNode were probably bad ideas to begin with); and re-think at least one of the others: PJClassOrInterfaceNode. If there are others that are still strange, please let me know which. Interestingly, Stephan has commented most of the other nodes - thanks! -Chris On Thu, Jun 20, 2013 at 5:52 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: