[antlr-interest] Problem with generated code
Thomas Brandon
tbrandonau at gmail.com
Wed Feb 13 10:45:08 PST 2008
On Feb 14, 2008 4:42 AM, Jim Idle <jimi at temporal-wave.com> wrote:
> 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;
> }
>
> ...
> :
Isn't that going to be hoisted into contexts prior to entering the
rule and so before the @init action where identifier will have an
incorrect value?
Tom.
>
>
>
>
> > -----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