Its massively helpful if you provide a complete (and working! - i.e. 
compiles) example.

I would encourage you to go back to the PR::D POD and follow the examples for 
this kind of thing VERY CLOSELY.

The (a) problem is that "ident" does not disallow keywords:

use strict;
use vars qw($parser $text %top);
use Data::Dumper;
use Parse::RecDescent;
$RD_WARN  = 1;
$RD_HINT  = 1;
$RD_TRACE = 120;
my $grammar = q
{
        <autotree>
        disj      : conj disjOp disj | conj
        conj      : term conjOp(?) conj | term
        term      : qualif(?) term2
        term2     : brack | phrase | ident
        brack     : '(' disj ')'
        phrase    : '"' ident(s?) '"'
        ident     : /[a-zA-Z\d]+/ {$return=($item[1]=~/^(or|and)$/i)?undef:$item[1]}
        qualif    : ident '='
        conjOp    : /AND/i #| ''
        disjOp    : /OR/i
};
$parser = Parse::RecDescent->new($grammar);
print Dumper($parser->disj('a or b'));


This turns out to be critical because of your requirement that the keyword 
operator "and" be optional.  This works by failing the rule in the exception 
case.  Another way to do it is to use the lookahead feature.

On Friday, May 21, 2004 Jonas Wolf said:
> Following your recommendation, I have altered the query to read as 
> follows:
> 
> my $grammar = q
> {
>         <autotree>
>         disj      : conj disjOp disj | conj
>         conj      : term conjOp(?) conj | term
>         term      : qualif(?) term2
>         term2     : brack | phrase | ident
>         brack     : '(' disj ')'
>         phrase    : '"' ident(s?) '"'
>         ident     : /[a-zA-Z0-9]+/i
>         qualif    : ident '='
>         conjOp    : /AND/i #| ''
>         disjOp    : /OR/i
> };
> 
> This should fix the precedence issue with 'qualif'. However, this shows 
> the same misbehaviour
> as when I tried it. Again, a query 'a or b' is interpreted as 'a AND or 
> AND b'.
> 
> Any ideas?
> 
> Jonas
> 
> 
> 
> 
> 
> Jonas Wolf/UK/[EMAIL PROTECTED]
> 21-05-04 09:16
>  
>         To:     "Ron D. Smith" <[EMAIL PROTECTED]>
>         cc:     [EMAIL PROTECTED]
>         Subject:        Re: grammar problems
> 
> 
> I would like to parse boolean queries like the following:
> <=> means the two queries represent the same structure
> 
> this and that <=> this that
> this or that
> a b or c d <=> (a b) or (c d) <=> (a and b) or (c and d)
> "this phrase" word <=> "this phrase" and word
> abstract = error or content = mistake <=> (abstract = error) or (content = 
> 
> mistake)
> ...
> 
> I hope that clarifies things.
> 
> > conj      : term conjOp(?) conj | term
> 
> Yes, that seems like a good alternative, I will have to try if it works.
> 
> Thanks, Jonas
> 
> 
> > Hello,
> > 
> > I recently downloaded the Parse::RecDescent package to parse
> > boolean queries. I have several questions, not necessarily about
> > the package itself, but rather about my grammar. 
> > 
> > I am currently using the following grammar:
> > 
> > my $grammar = q
> > {
> >         <autotree>
> >         disj      : qualif(?) conj disjRec(s?)
> >          disjRec  : disjOp conj
> >         conj      : term conjRec(s?)
> >          conjRec  : conjOp term
> >         term      : brack | phrase | ident
> >         brack     : '(' disj ')'
> >         phrase    : '"' ident(s?) '"'
> >         ident     : /[a-zA-Z0-9]+/i
> >         qualif    : ident '='
> >         conjOp    : /AND/i
> >         disjOp    : /OR/i
> > };
> > 
> > I have several problems with this.
> > 
> > Firstly, the precedence isn't quite what I want in 'qualif'. I would
> > like 'ident' to bind tightly to whatever comes next to it. Currently
> > it seems to associate it with the whole 'disj' that comes after.
> 
> You do not provide any examples of what you are trying to parse, which 
> would 
> help.  IMHO what you mean by the above paragraph is not clear so I don't 
> know 
> what you "want".
> 
> > 
> > Secondly, I would like the 'conjOp' operator to be optional, and that
> > the parser recognises this. This means a query for 'a b' would be
> > interpreted as 'a AND b'. I tried replacing the conjOp rule with
> > 'conjOp : /AND/i | ""', but this does not work, as now a query 
> > 'a AND b' is interpreted as 'a AND and ...'.
> 
> Perhaps:
> 
> conj      : term conjOp(?) conj | term
> 
> It might help if you followed the example given in the PR::D POD more 
> closely.
> 
> > 
> > Any help would be appreciated.
> > 
> > Thanks, Jonas.
> 
> 
> --
>  Intel, Corp.
>  5000 W. Chandler Blvd.
>  Chandler, AZ 85226
> 
> -- 
>  Intel, Corp.
>  5000 W. Chandler Blvd.
>  Chandler, AZ  85226
> 
> 
> 
> 
> 


--
 Intel, Corp.
 5000 W. Chandler Blvd.
 Chandler, AZ 85226

-- 
 Intel, Corp.
 5000 W. Chandler Blvd.
 Chandler, AZ  85226


Reply via email to