That was a very nice explanation. I would request you to put it in some wiki, so that it would help a lot of entry level parser programmers.
Thanks, Gokul. On Mon, Mar 8, 2010 at 9:28 PM, Jim Idle <[email protected]> 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: [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 > 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.
