Reshaping Parse Trees
September 22, 2016
Parsing and internal parse structures — trees — are not something that development tools readily expose. It is assumed that most users are comfortable with numerous features that depend on parsing, such as formatting, code block collapsing/expanding, code advisors and so on, but aren’t really interested learning the formal code structure. In SQL Developer 4.2 we have attempted to encourage users to experiment with parse trees.
The location, where the new feature is introduced, is somewhat obscure — it is the former 4.2 “Outline” panel, which is was accessible via “Quick Outline” context menu item. Minor name change reflects the amended functionality
Perhaps some explanation of what you see at the left panel is warranted. Oracle PL/SQL language is ADA derivative, which formal grammar can be found here. In the above example, the top most node labeled
subprg_spec has been recognized as matching the first production for the rule
subprg_spec : PROCEDURE_ IDENTIFIER .fml_part. | FUNCTION_ designator .fml_part. RETURN_ ty_mk ;
Consequently, it has 3 children labeled
TEST (which is
identifier) and ,
For some obscure reason, there is no trace of this genuine formal grammar in oracle PL/SQL documentation, and “railroad” syntax diagrams are different. The good news, however, is that oracle documentation SQL grammar matches almost verbatim to the parse trees that SQL Developer exposes.
Playing with parse trees
Some nodes, such as those labeled with
fml_part in the example above, are collapsed. This is because parse trees for even moderately long code become overwhelming. Expanding tree branch manually is quite laborious; this is why there are 2 more effective ways to accomplish it.
Even though the root node is not collapsed, this context menu item is still there, and this action will expand all the collapsed descendant branches.
Selectively collapsing/expanding tree branches
The second alternative is little more sophisticated. Suppose, in our working example you would like to have all the nodes with payload
fml_part expanded. Then, you click onto the second button on the toolbar (it is marked with plus symbol and “Collapse nodes with payload” tooltip).
If you check the
fml_part menu item, then all the nodes with this payload become expanded.
A sharp eyed reader might have noticed that, by default,
select is expanded, while
seq_of_stmts is collapsed. This is because code outline is working not only for PL/SQL editor but also SQL Worksheet. In SQL worksheet queries —
select statements — are the main laborers, this is why their structure is expanded. However, if you work mostly in PL/SQL editor, then those
select statements are less interesting. For example, a
which is a part of a cursor declaration can be collapsed, unless a user decides to investigate it. As for
seq_of_stmts, again, PL/SQL package bodies are frequently very large, so having collapsed sequence of statements — the bulk of procedure or function — is handy.
Selectively hiding the nodes
Another way to bring a parse tree to manageable size is hiding the nodes. In general, if node disappears, something must be done about this node children. Naturally, orphans become attached to node’s parent. For example, deleting node B, reattaches grand children C and D to node A.
Which nodes are not so much interesting? Consider a typical SQL query
A chain of tree nodes marked with
select_list faithfully reflects SQL grammar, but a user might want to see more concise picture. The 3rd (“Hide nodes with payload”) button on toolbar serves this purpose
select_list menu item (it is unchecked by default) reshapes the tree like this
There is only so much that tree reshaping can do. For large trees it is laborious to search for interesting information. In the next installment we’ll describe an approach which is more satisfying for a reader with database background — querying.