[antlr-interest] Another Newbie Question

mzukowski at bco.com mzukowski at bco.com
Mon Oct 8 10:35:29 PDT 2001


> -----Original Message-----
> From: Tiller, Michael (M.M.) [mailto:mtiller at ford.com]
> Sent: Monday, October 08, 2001 10:26 AM
> To: antlr-interest at yahoogroups.com
> Subject: [antlr-interest] Another Newbie Question
> 
> 
> While I'm still hoping for additional responses to my 
> previous e-mail titled "Newbie Question", I have another 
> related question that I was hoping somebody might be able to answer.
>  
> I have a rule in my grammar that looks like this:
>  
> modelica_file
>   : (within:within_clause)? (defs:stored_definition)* EOF!
>   ;
>  
> This is my top-level production rule.  The strange thing for 
> me is that when I write code like this:
>  
>      parser.modelica_file();
>      t = (CommonAST)parser.getAST();
>  
> The variable "t" is returned with the tree for the within 
> clause and not for the entire "modelica_file" rule.  Is this 
> normal?  

Yes, you haven't specified a root, so the "defs" are added as siblings to
the root, not as children.  

> I notice that the generated code looks like this:
>  
>    modelica_file_AST = (AST)currentAST.root;
>  
> What I was hoping for was more like:
>  
>    modelica_file_AST = (AST)currentAST;
>  
> In order to make it so that the "stored_definition" trees 
> didn't get cut off, I changed my top level rule to:
>  
> modelica_file
>   : (within:within_clause)? (defs:stored_definition)* EOF!
>     { ## = #(#[FILE, "<file>"], ##); }
>   ;
> 
> I introduced this "FILE" token type in my lexer (as 
> protected) and I thought this was an appropriate way to deal 
> with this situation (I'm also trying to use it in other 
> contexts to identify important structural entities).  Anyway, 
> this works (although it took me a while to figure out exactly 
> how to do it).  Now, the AST returned after the 
> "modelica_file" method is called on the parser does include 
> both the within_clause production and all stored_definitions as well.
>  
> I guess my first question is, have I done something stupid here?
>  
> OK, next question.  I tried to write a TreeParser for this 
> with a toplevel rule that looked like this:
>  
> modelica_file
>   : #(FILE (within_clause)? (stored_definition)*)
>   ;
>  
> Isn't this the correct way to represent this "artificial" node type?
>  
> I ask because when I run the tree parser, it fails with an 
> error saying:
>  
> expecting FILE, found '<file>'


You probably have a mismatch in your token definitions.  Are you importing
your parser's vocabulary into your tree parser?  It's trying to match token
types, but they may not be defined as the same.  Look at the token types
files for your parser and tree parser and see if the entry for FILE is the
same.  It better be.


> First, I don't quite understand why it is even paying 
> attention to the token text as opposed to the token type?!?  
> I obviously don't understand something about tree parsers.  
> But that isn't even the problem.  If I change the token text 
> to be "FILE", then I get this message:
>  
> expecting FILE, found 'FILE'
>  
> Huh?!?
>  
> So, my second question is what am I doing wrong here?!?!?  
> I'm totally confused by this.
>  
> Thanks
>  
> --
> Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20011008/29bff1dd/attachment.html


More information about the antlr-interest mailing list