> Hi Orton, Actually its Yves...
:-) > thanks for your explanation on CFG. I already feared that my knowledge > about parsers are not deep enough to understand the real underlying > problem why Damian didn't already spent us this feature. Well I suspect he's more concerned with feature that are traditionally in the domain of parsing context free grammars, a well studied and quite complex field. > > > > > exor : Mr ^ Mrs ^ hybrid > > > > Hmm, again (afaict) as presented this is a non-context-free > constraint. > > > > But with a bit of gymnastics you can do this with P:RD > using regexes: > > > > salutation : /Mrs?/ first_name last_name > > first_name : /(?!Mrs?)\S+/ > > last_name : /\S+/ > > > > Or using lookahead matches > > > > salutation : 'Mr' ...!'Mrs' > > | 'Mrs' ...!'Mr' > > but this works only for terminals No, using lookahead matches applies to nonterminals as well. But you're (sortof) correct about the regex solutions. >and this is again not what > I need. I've choosen Mr and Mrs as subrule names just for an easy > demonstration what is needed, but in general this is necessary > for subrules: > > exor : subrule-1 ^ subrule-2 ^ subrule-3 > subrule-1: subrule-11 ^ subrule-12 .... Umm, ok now maybe im confused, but I would go with Marco on this. This is exactly the same as option : optlist optlist : rule1 | rule2 | rule3 rule1 : subrule1 | subrule 2 Optlist may now only match 1 of rule1 rule2 or rule3, and likewise if it does match rule1 it may only be subrule1 or subrule2. I believe the impact of changing the above to option : optlist(s) optlist : rule1 | rule2 | rule3 rule1 : subrule1 | subrule 2 which allows any selection of the rule1 is causing you problems. It is the rule option that allows multple optlist elements to be chosen, not optlist itself. > but I guess this is again not possible with CFG parsers. Er, im not so sure. I think it may be just that the grammar needs to be written with a little more care. Dont forget that two dissimiler grammars can parse the same language. And one of those grammars may not be supported by P:RD. This can bee seen by looking at the examples in the docs. Specifically the ones dealing with the <leftop:> command. > Anyway, the generated parser code is pure perl and we can solve > any of these problems with perl code in actions, why shall this > not be possible for P::RD direct? Parsing a CFG is a mechanical process. Anticipating every users needs for contextual sensitivity would mean P::RD still wouldnt be written yet. :-) > You see, I've no guess how complicated it will be but perhaps it's > a greenly thought from me: > > "Anyone who is able to create such a beast like Parse::RecDescent > is able to do anything!" Yah. TheDamian is a pretty awesome programmer but I suspect hes not going to implement your requests as they are already implementable with a bit of elbow-grease using the current module and would probably only be useful to such a small set of users that it wouldnt make sense. Personally id far prefer to see Parse::FastDescent and Perl6 finished sooner than later. :-) BTW, you may find reading the Red Dragon (Compilers, Priciples and Techniques by Aho, Sethi, Ullman) to help our with some of the conceptual issues. Yves
