[antlr-interest] Function Call,

[Ric Klaren]

On 6/30/05, Craig Main <craig at palantir.co.za> wrote:
> The problem has nothing to do with the type of brace used. I was trying both
> 
> I have tried both '(' and '[' because the tree output uses '(' and ')' and I
> wanted to see what was what.

Make very sure that you made a clean built of your project. And no
stale xxxtokentypes.txt is around. Observe that you have the right
build order for lexer, parser, treeparser and they all have the same
idea over which token is what. (manually check the xxtokentypes.txt
files) verify importVocab/exportVocab use. Also make sure you have no
typo's in token names antlr gives no warnings if you make a typo it
just silently adds a token!

> If I try and generate with -traceTreeParser, I get unresolved symbols
> everywhere because currentAST does not exist.

That has to be a bug. Which antlr version are you using?

> The grammar is quite simple.
> It boils down to the following simple rules that I cannot seem to match. (I
> have been at this for three days, and I am tearing my fricking hair out).
> 
> The try output, which I have printed below shows 'func' under ELIST.
> 
> I have enclosed all the combinations I have tried so far to get it working.
> 
> With the following input.
> FRED = 100;
> TEST = 10 + 10;
> ITEM = TEST + 10;
> TEMP = 4 + func[10+1,2];
> 

> The node 'func' is not recognised by the tree grammar, and I cannot figure
> out why.

If the -traceTreeparser does not work at least add a print to the top
of each treeparser rule in the init section:

rule { System.out.println("rulename"); }:    .... ;

That way you know where the treeparser takes a wrong turn. Or trace it
in a debugger.

> I have printed the tree, which looks like this.
> ( RULESET ( = FRED 100 ) ( = TEST ( + 10 10 ) ) ( = ITEM ( + TEST 10 ) ) ( =
> TE
> MP ( + 4 ( func ( ELIST ( + 10 1 ) 2 ) ) ) ) )
> 
> ELIST appears in the tree, but METHOD_CALL does not.
> Why does it not appear in the tree? Perhaps that is the problem?

The rule that builds the tree:

> function                : id:ID^ {#id.setType(METHOD_CALL);} LPAREN!
> arguments RPAREN!

> arguments               : (expression (COMMA! expression)*)?
>                           {#arguments = #(#[ELIST,"ELIST"], arguments);}

> Func  appears in the tree, but not METHOD_CALL.

You see the correct behaviour: You only do a setType no setText. The
supplied printers only prints the getText value. So I suspect that
underneath the func is a method_Call type.

<Aside note>

> arguments               : (expression (COMMA! expression)*)?
>                           {#arguments = #(#[ELIST,"ELIST"], arguments);}

This is safer written as:

arguments               : (expression (COMMA! expression)*)?
                          {#arguments = #(#[ELIST,"ELIST"], #arguments);}

or as:

arguments               : (expression (COMMA! expression)*)?
                          {## = #(#[ELIST,"ELIST"], ## );}

That you can address arguments directly is an artifact of the codegenerator.
</Aside note>

> expression
> returns [object result]            {result = null;object l,r;}
>                                  : #(PLUS l=term r=term) {result=Add(l,r);}
>                                  | #(MINUS l=term r=term)
>                                  | #(MULTIPLY l=term r=term)
>                                  | #(DIVIDE l=term r=term)
> 
>                                  | #(METHOD_CALL( #(ELIST (expression)*)))

> // also tried                    | #(METHOD_CALL #(ELIST (expression)*))

I would suspect that this one should work.... I'm betting on a mistake
with build order or vocab im/export or a typo.

If you want some example stuff: the grammar for MoDeST available at:

http://fmt.ewi.utwente.nl/tools/motor/?section=download

Has a working example of a similar language + treewalkers. The parser
is pretty ugly (tried to do too much at once) but should give an
example of how to build a tree (uses more imaginary tokens to tag
things) and how to walk. The treewalkers are in the backend/mobius
subdir.

Cheers,

Ric