RE: Feature wishlist for P::RD 2.0 ore perhaps 1.81

> 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