I don't think it will change the way the symbol table is implemented.
I was just thinking about possible overlap of changes, so it would be
safer to work with the branch to ensure that merging later is easier.
In any case, the parser will create an index expression when it sees
something like "java.lang.String (ARGS)". When it evaluates this
expression, it will first look up the value of "java". The current
implementation throws an error if it does not find a definition. So I
suppose that is the place to put the code that will attempt to do
something with the expression instead of generating an error. At this
point, you will have access to whatever is contained in the
tree_index_expression object. In this case, you have the initial identifier
("java"), the list of indices ("lang", "String" and ARGS) and the
types of the indices (".", ".", and "("). Does that help?