[antlr-interest] Problem with generated code

Jim Idle jimi at temporal-wave.com
Wed Feb 13 09:42:38 PST 2008


The predicates can be hoisted (this is a feature), hence the identifier 
is not available in the context that the predicate runs. You can avoid 
this by using a scope:

xxx[String ident]
scope
{
  String identifier;
}
@init
{
	$xxx::identifier = ident;
}

...
:

> -----Original Message-----
> From: Jamie Penney [mailto:jpen054 at ec.auckland.ac.nz]
> Sent: Tuesday, February 12, 2008 5:10 PM
> To: antlr-interest at antlr.org
> Subject: [antlr-interest] Problem with generated code
> 
> Hi All,
> 
> I am having an issue that I wonder if someone could help me with. I
> have
> a rule:
> 
> // For contextual keywords like get, set and yield
> contextual_keyword[string identifier]
>     :    { input.LT(1).Text == $identifier }? IDENTIFIER
>         -> {$identifier == "from"}? FROM[$IDENTIFIER]    // Transform
> all known contextual keywords into
>         -> {$identifier == "let"}? LET[$IDENTIFIER]        // their
> corresponding imaginary token
> ......................
>         -> {$identifier == "remove"}? REMOVE[$IDENTIFIER]
>         -> IDENTIFIER    // For unknown ones
>     ;
> 
> That seems to first action seems to be pulled up into whatever other
> rules use this one in the generated code. So I end up with this sort 
of
> thing:
>                     int alt80 = 2;
>                     int LA80_0 = input.LA(1);
> 
>                     if ( (LA80_0 == IDENTIFIER) )
>                     {
>                         int LA80_1 = input.LA(2);
> 
>                         if ( ( input.LT(1).Text == identifier ) )
>                         {
>                             alt80 = 1;
>                         }
> 
> 
>                     }
> 
> Which won't work because identifier hasn't been defined yet. The 
actual
> call to contextual_keyword() doesn't happen until well after this
> section, as it is further down the rule tree. So my question is, why 
is
> the first action in this rule being brought up, even though it has a
> dependency on the parameter passed to the rule? Is there a way to 
avoid
> this behaviour?
> 
> Thanks,
> Jamie Penney
> 
> --
> Jamie Penney
> 
> http://www.jamiepenney.co.nz




More information about the antlr-interest mailing list