[antlr-interest] Function Call,

[Craig Main]

Hi,

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.

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

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];

I get the following output.
[SimpleAppConfig]: term
[SimpleAppConfig]: FRED = 100
[SimpleAppConfig]: TEST = 20
[SimpleAppConfig]: ITEM = TEST10
<AST>: unexpected AST node: func
[SimpleAppConfig]: TEMP = 4

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

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?

Func  appears in the tree, but not METHOD_CALL.

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)*))
// also tried 	               | #(ELIST ID)
// also tried                    | #(ELIST (expression)*)
// also tried                    | #(METHOD_CALL ID)
// also tried                    | #(METHOD_CALL ID #(ELIST (expression)*))
// I think I have tried other
// combinations over the last three days too.
                                 | result=term {log.Info("term");}
                                 ;



Here is the parser, which should probably put METHOD_CALL into the tree
somewhere?

rules                   : (statement)* 
                          {#rules = #([RULESET, "RULESET"], #rules);}
                          EOF!
                        ;
statement               : assignment_statement SEMI!
                        ;
assignment_statement    : id:ID ASSIGN^ expression
                        ;
expression              : term ((PLUS^|MINUS^) term)*
                        ;
term                    : factor ((MULTIPLY^|DIVIDE^) factor)*
                        ;
factor                  : value
                        ;
value                   : (ID LPAREN) => function
                        | literal
                        ;
function                : id:ID^ {#id.setType(METHOD_CALL);} LPAREN!
arguments RPAREN!
                        ;
arguments               : (expression (COMMA! expression)*)?
                          {#arguments = #(#[ELIST,"ELIST"], arguments);}
                        ;

literal                 : id:ID^
                        | fl:FLOAT^
                        ;

-----Original Message-----
From: Ric Klaren [mailto:ric.klaren at gmail.com] 
Sent: 30 June 2005 12:08 AM
To: Craig Main
Cc: 'ANTLR Interest'
Subject: Re: [antlr-interest] Function Call,

Craig Main wrote:
> Hi,
> 
> I am *still* struggling.
> What am I missing here?
> 
> I have tried the following rule.
> #(METHOD_CALL( #(ELIST (expression)*))) {log.Info("Method Call");}
> 
> I also tried to match just
> #(ELIST ( expression )* ) {log.Info("ELIST");}
> 
> It also doesn't match. The log output is never produced.
> 
> It still doesn't match.
> The output is as follows.
> 
> rules.g:33:60: warning:Rule 'expression' returns a value
> RuleLexer.cs(108,12): warning CS0219: The variable '_token' is assigned
but
> its value is never used
> 
> Tree Printout, trying to match TEMP = 4 + func[10+1,2];

So the input uses '[' and ']' as function argument grouping?

 > value                   : (ID LPAREN) => function
 >                         | literal
 >                         ;

Is your LPAREN a '(' or a '[' ? I suspect that the treeparser entered 
the literal rule in stead of the function one.

In case of doubt generate the treeparser with the -traceTreeParser and 
meditate on the output of that. This makes it really hard to see where 
the parser takes a wrong turn... The various tracing options to antlr 
for the generated lexers/parsers/treeparsers are some of your best friends.

Cheers,

Ric