lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: Precedence parser: NOT/AND, disableCoord
Date Thu, 17 Mar 2005 14:15:17 GMT
On Mar 15, 2005, at 3:57 PM, Paul Elschot wrote:
> On Tuesday 15 March 2005 01:55, Erik Hatcher wrote:
>> I'd welcome others to give it a try, though.  I'm still learning how 
>> to
>> accomplish things with JavaCC.
> The basic rule is the deeper the nesting of the grammar construct,
> the higher the parsing precedence of the corresponding operator.

Right.  I got that much :)  I did implement this locally and other 
tests broke (I sent the details to the list, but have since reverted my 

>> I've struggled (and still struggling) with this same thing myself.
>> AND/OR are problematic because of the nature of boolean clauses, which
>> individually have their own required/prohibited flags, not in
>> _conjunction_ with another clause.
> I'd recommend to use getOrQuery() and getAndQuery() methods to
> map to a boolean query via the clauses, and to implement corresponding
> grammar constructs that just collect the clauses. Top level for OR,
> next level for AND, next level for NOT.
> Mixing - and NOT is no problem, but + and AND is not nice.
> Allowing the mix should probably throw a ParseException in
> some unexpected corners. It might for example be possible to
> disallow + on the level of AND.

Good ideas.  I'd love to fiddle with this, but realistically I won't 
for a while.  I'd be happy to apply patches and try out changes.

> How much compatibility with the existing parser is needed,
> in particular with the coordination factor?

That's a great question.  For it to replace QueryParser and fix the 
weirdnesses with it, the syntax that is currently accepted should be 
supported and generate equivalent queries when possible and fixed 
queries where QueryParser was wrong/awkward.

>>> However, from what I see now in the precedence parser,
>>> giving up might have been premature. It seems to be possible
>>> to make the mix after all.
>> I believe its possible, but I won't be spending time on it in the next
>> few weeks at least - anyone interested in the next generation query
>> parser is encouraged to pick up the torch.
> I suppose another goal is to get the span queries in the parser.
> Once the boolean OR/AND precedence works, it is also possible
> to add operators with even higher precedence for the span queries.
> Would you, or someone else, have any ideas on what the syntax for these
> should look like? How much of the span functionality should be made
> available via the query language?

Support for SpanQuery's will be added in my custom query parser 
(proprietary under contract).  The syntax I have to use is not 
something that is generalizable anyway, but I'm sure my learning of 
JavaCC will help us add this stuff eventually (if no one beats me to 
it).  I think it'd be cool to at least have support for ordered sloppy 
phrase queries.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message