[antlr-interest] Function Call,
Craig Main
craig at palantir.co.za
Wed Jun 29 23:56:46 PDT 2005
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
More information about the antlr-interest
mailing list