Launch higher level UAST abstractions for Babelfish about okrs

[marnovo]

[OKRs Review]:

@dennwc @smola @mcuadros to review/clarify [P2] Structural pointers.

[marnovo]

[OKRs Review]: Removing link to #23 since too low level for OKRs.

[juanjux]

Status as of friday 29th of june:

• Higher level apis unneeded since the semantic objects are in the exported UAST.
• Higher level categories for nodes are defined and implemented, but in PR state in the SDK v2 semantic branch (so not done, but close).
• Structural pointers are not done.

[dennwc]

Update regarding structural pointers. I think we can safely drop them from the list of objectives, because:

• If the meaning of the node is known and it's worth to represent it in UAST we can define it as a high-level type instead of roles + structural pointers.
• If the node is unique and exists only in one language, than it doesn't make sense to define roles for it, thus structural pointer will have no effect.

[juanjux]

@dennwc structural pointers are for relational analysis of AST nodes which is a different problem than the one the high level types solve.

[dennwc]

@juanjux Not sure what you mean by this. Can you elaborate?

Structural pointers were meant to solve ambiguity for native AST nodes by presenting the pointer to a "structural root". High-level types solve this because there is no ambiguity. If you have a function name, you will always recognize it because the structure of function declarations is unified.

[juanjux]

Structural pointer were for defining the semantic root of a node so a researcher could do, for example, analysis about how different languages organize the trees of common objects (without ambiguity) but were not intended to be the solution for high level concepts, for that before the latest changes with the new DSL the idea from the meetings was to have a set of standard functions implemented by each driver that would return the objects of a specific type with an unified structure.