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

Gokulakannan Somasundaram gokul007 at gmail.com
Mon Mar 8 14:47:36 PST 2010


Jim,
    While your explanation is perfectly valid, i am having trouble
understanding the term context sensitive parsing. I understand that context
is set by some rule, which has been parsed before. This is used in semantic
predicates to choose the correct alternatives.
So in those cases, should i understand it like the following
a) the rule which sets the context, will never look beyond a particular set
of tokens( say n)
b) The tokens which come after this count n, can use that as a variable for
determining alternatives.

Please explain me on this.

Thanks,
Gokul.

On Mon, Mar 8, 2010 at 9:28 PM, Jim Idle <jimi at temporal-wave.com> wrote:

> 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
>
>
>
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>


More information about the antlr-interest mailing list