Node info

[puzrin]

Problem:

• Minimal info is good for serialization, but can be not enougth for fast traverse
• What kind of generic fields do we need for abstract node?

Fields

• source mapping info
  • range of line/column info?
• ? block or inline node
• ? can have children
• ? nesting level
• ? self-closing
• TBD

Checklist

• Make sure new node types can be added and will not break existing tools compatibility

[geyang]

The current node type is good enough to me. I really don't mind working with a custom node syntax, be it 2-level array or tree. Because there is no standard amongst the different parsers, effort in making a nice node format would not have a large positive impact.

[puzrin]

Initial problem is related to parser algorythms. Sometime scanner needs to discad data and jump back, or modify last created node. The same for "path stack" to current node. This is more difficult with existing arrays and recursive calls.

But this can be improved via better data store:

• Use double linked lists
• Don't create complex objects until the end. Use typed arrays + fixed-length set of pointers to describe tokens, substring start/end and so on (emulation of C struct). In this case lists/stacks can be implemented very effective.

And we still can keep 2-level lists. Those are more easy to scan (without recursion), but more difficult to modify. Situation with AST is reverse.

[geyang]

And we still can keep 2-level lists. Those are more easy to scan (without recursion), but more difficult to modify. Situation with AST is reverse.

What about use a component array with keys that allow easy component loop up and easly modify:

how to generate these keys is an art in itself. In some sense incrementing integers is good enough and other id generation doesn't get you much.

AST: 
{ root: component_id,
componet_id_list: [component_id1, id2 ...],
component_id1: component 1,
component_id2: component 2 { child_id1, child_id2}
}