I really think you are beginning to make this way more complicated than it really is. You need to step away from your current pursuit of predicates and so on and go back to fundamentals. You are trying to get the parser to do way more than parser should do. I know it is tempting because it seems that the parser will do a lot of validation for you, but it is (generally) the wrong way. You want your parser to be as simple as possible, accepting anything that is good syntax from a pure string together of tokens point of view, THEN apply semantics to see if anything fails. This way you r parser rules can accept all the clauses that might be correct (as in all syntactically sound combinations), then reject the incorrect ones by semantic analysis. Your parser will be simpler, your users will thank you for the improved error messages and the whole thing will be easier to maintain.
Basically if you find yourself in the nitty-gritty like this, you are probably heading down the wrong path or flogging a dead horse ;-) You could use backtracking mode for this, but then your error messages will be even more arbitrary. For the predicate, don't forget that the prediction will still select a rule and try the predicate. Perhaps you could use gated predicates on the 'invocation' of the rule so that it is not 'called' if it won't match, but once you are in a rule you have to do something like this; r : (pred1)=>rule1 | (pred2)=>rule2 | // neither of the above, match nothing ; But then you start need to set state flags, test the flags, etc. You soon end up with a lot more work than just using a semantic analysis phase after the initial parse. You will also have to deal with the absence of flags due to syntax errors and so on, whereas if you defer to semantic analysis as a separate phase, then you will be able to rely on a sound syntax. So: 1) Don't try to influence the paths the parser takes - let the tokens do that; 2) Afterwards, in the tree walk, determine whether the various combinations of clauses are correct, issue good errors here if not; 3) Generate code (or whatever it is you are doing) in the knowledge that it is all good from here. Jim From: [email protected] [mailto:[email protected]] On Behalf Of Naveen Chawla Sent: Saturday, October 17, 2009 10:45 PM To: [email protected] Subject: [antlr-interest] How to make a syntactic predicate exit a rule completely Ok, so even if all syntactic predicates have failed in a particular rule, that rule is still included as "matched" in that analysis! Is this true or are my tests wrong? This is not what I hoped. I was hoping that upon complete failure of all syntactic predicates in a rule, the rule becomes disregarded, and that "disregarding" is cascaded as far up as possible, and an alternative path is attempted. Is this how it's works, or am I missing something? Or is there a way, using actions, to "force" the exiting of a particular rule as if it had not been matched at all? Many regards, N --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address
