[antlr-interest] Another Newbie Question

[Tiller, Michael (M.M.)]

-----Original Message-----
From: mzukowski at bco.com [mailto:mzukowski at bco.com]
Sent: Monday, October 08, 2001 1:35 PM
To: antlr-interest at yahoogroups.com
Subject: RE: [antlr-interest] Another Newbie Question 
 
> 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 don't quite understand what you mean by a root.  Do you mean I should have yet another top-level rule like:
 
modelica_source
  : modelica_file
  ;
 
I tried this and it doesn't seem to have an effect.  Perhaps something like this?...
 
modelica_classes
  : file:modelica_file { ##=#(#[FILE,"<file>"], #file); }
  ;
 
This works, but it just seems strange to me that the solution involves both an additional production rule and some hand tweaking of the tree construction.  I'm not sure which approach is better.

> 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. 

Excellent!  Very observant.  I had used the appropriate importVocab option in my original grammar, but for the tree parser I forgot it.  I guess I was just thrown completely off track by the fact that it would complain with statements like "expecting FILE, found 'FILE'".  Anyway, now I'm getting a new error, but its more along the lines of what I would have expected.
 
Thanks.

> 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 


Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20011008/c77f7d52/attachment.html