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 changes).
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.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
