Re: Pluging hooks in the parser?

[John W. Eaton]

On 14-Jun-2007, Michael Goffioul wrote:

| On 6/14/07, John W. Eaton <address@hidden> wrote:
| > | Maybe it's still possible to emulate all this (although it might become 
very
| > | tricky). But I thought that a more generic implementation could be based 
on
| > | some parser hooks. So I just wanted to know whether this was imaginable.
| >
| > Yes, I suppose so.  Since this involves symbol lookup, it would
| > probably be best to work on the object branch or wait until the new
| > symbol table code is merged with the CVS trunk.
| 
| Indeed. I don't know how this could be implemented, but from a java perpective
| (which is why I'm asking), looking for the symbol "java" alone wouldn't work
| as this does not have any meaning in the JVM. What has a meaning is the
| full class name "java.lang.String". This might have some impact on possible
| implementations.

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?

jwe