[antlr-interest] Using previously matched parser rule in decision making

[Jim Idle]

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: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
> bounces at antlr.org] On Behalf Of Kieran Simpson
> Sent: Monday, March 08, 2010 12:04 AM
> To: Gokulakannan Somasundaram
> Cc: antlr-interest at antlr.org
> 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 <kierans777 at gmail.com
> > <mailto:kierans777 at gmail.com>> 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