See earlier reply - if you want to sue them in predicates then you have to use
scopes.
However, I think that once you start down this that you are probably
approaching the grammar incorrectly. This usually arises from trying to program
a grammar from a normative spec for a language which is usually written in an
LALR type approach and is also a documentation exercise so it tends to use
things that are ambiguous syntactically but help to document the structure such
as ID (rule_parameter_ascii | rule_paramter_non_ascii).
Other ways you can get down this path is because you are trying to impose too
much structure at the parser level. The approach to try for is to defer as many
errors from the lexer (in fact you should not really have any that you don't
catch programmatically) into the parser, then as much as possible change
syntactic errors into semantic errors, preferably in the tree walker.
So, the parser should accept anything that is syntactically sound, even if it
is semantically not allowed, then issue neater errors in a semantic context of
either the parser, or usually more easily the tree walker.
So a ruleb is only allowed after a rulea if XYZ is seen, but don't try to
exclude that syntactically, juts accept it then check the conditions after:
rulez: rulea (XYZ { flag=true;} )? (ruleb* { if (flag == false) {
sout("Constructs like ruleb must have XYZ"); } }) ;
And so on.
Jim
> -----Original Message-----
> From: [email protected] [mailto:antlr-interest-
> [email protected]] On Behalf Of Kieran Simpson
> Sent: Monday, March 08, 2010 12:04 AM
> To: Gokulakannan Somasundaram
> Cc: [email protected]
> Subject: Re: [antlr-interest] Using previously matched parser rule in
> decision making
>
>
> > What Jim is suggesting is something like this
> >
> > ruleA: ruleB[true];
> >
> > ruleD: ruleB[false];
> >
> > ruleB[boolean isRuleA]:
> > {isRuleA}? .....
> > | .....
> > ;
> >
> > Usage of semantic predicates. But i think there is an issue with
> that.
> > From ruleA / ruleD, if you decide to do a look ahead like LA(n), and
> > if that lookahead goes to B, then this won't carry the boolean
> > parameter and you might face some issues and the error thrown will
> not
> > be intuitive.
> >
> You are correct Gokulakannan. I tried the semantic predicate approach
> as well (just to see if it was a better approach) and in some of the
> "synpred fragment" functions generated by the C target, I got compiler
> errors as the functions was trying to use the rule parameter (in this
> example, isRuleA) when the rule argument wasn't passed to the fragment
> function. The fragment function didn't even declare a parameter in the
> signature to match the rule parameters. I eventually used a
> combination
> of parameter passing and target language if conditions. It didn't add
> to much to the grammar.
> > Ideal way according to me is
> >
> > ruleA: ruleB_A;
> >
> > ruleD: ruleB_D;
> >
> > ruleB_A :....;
> >
> > ruleB_D : ....;
> >
> > If there are lot of things that are common, factorise them as a
> > seperate rule / seperate actions. Hope my suggestion was helpful.
> >
> > Thanks,
> > Gokul.
> >
> >
> > On Mon, Mar 8, 2010 at 8:55 AM, Kieran Simpson <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > Thanks for the suggestions.
> >
> > I had considered the parameter approach, I was curious to know if
> > there
> > was a smarter way.
> >
> > John B. Brodie wrote:
> > > Greetings!
> > >
> > > On Mon, 2010-03-08 at 13:50 +1100, Kieran Simpson wrote:
> > >
> > >> I have
> > >>
> > >> ruleA: ruleB;
> > >>
> > >> ruleC: ruleB;
> > >>
> > >> ruleB: ruleD;
> > >>
> > >> In ruleB I want to different target language actions to
> execute
> > based on
> > >> whether it was ruleA or ruleC that was previously matched. If
> my
> > >> understanding of syntatic/semantic predicates is correct, they
> > only look
> > >> forwards, not backwards.
> > >>
> > >> Is there a way (without refactoring the grammar) to in rule B
> > know which
> > >> rule it was invoked from (A or C) and make decisions
> accordingly?
> > >>
> > >
> > > Off the top of my head, pass a parameter.....
> > >
> > > ruleA : ruleB[true];
> > > ruleC : ruleB[false];
> > > ruleB [boolean fromA] : ruleD
> > > { if( fromA )then
> > > ....do this stuff....
> > > else
> > > ....do that stuff....
> > > };
> > >
> > > (the above probably is not precisely the correct meta-syntax,
> but
> > > hopefully you get the idea...)
> > >
> > > -jbb
> > >
> > >
> > >
> >
> > List: http://www.antlr.org/mailman/listinfo/antlr-interest
> > Unsubscribe:
> > http://www.antlr.org/mailman/options/antlr-interest/your-email-
> address
> >
> >
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-
> email-address
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
--
You received this message because you are subscribed to the Google Groups
"il-antlr-interest" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
