Hi, First, let me say something that wasn't obvious from my first mail. While I had opinions about the implementation, I have a lot of respect for your finding a problem, and going ahead and coding a solution.
On Tue, Dec 30, 2003 at 11:40:17AM +0100, Morus Walter wrote: > Dror Matalon writes: > > my $.02. > > > > Before having patches, I think it's a good idea to agree on what the > > "right" solution is. > I tried to raise that question in the first place. But there wasn't much > responce. Might be the time of the year when many people are busy with other stuff. > So I decided to make a concrete suggestion, how to change things. > > > Most of it is obvious using boolean logic, but we > > have some additional requirements like not having a query that only has > > a NOT clause. Is this the only exception? > > > To me the problem is, that there are two forms of queries > - boolean queries (a OR b AND c...) > - list of terms where some are flagged required and some are flagged forbidden > (a +b -c ...) (in two forms: with default or and default and) > > For each of these it seems pretty clear, what they mean, but if you start > to combine the two in one query, I don't know what that should mean. > > What's the meaning of a OR b c +d ? > (Acutally there must be two meanings, one for default or, one for default and). > Maybe it's obvious, but I fail to see it. You're right, it is confusing. Assuming default OR I would gess that the above means b c +d and assuming default AND it would mean +b +c +d Is there another interpretation? > > > > > As far as the actual patch, I would suspect that a better approach than > > using java would be to use precedence operations in the actual parser. > > Then you decide to do a complete rewrite of the query parser. > That's something I wanted to avoid. Ouch. I think you might be right. It might be a good idea to move this discussion to lucene-dev where we'd get more attention from the developers. This seems more like a developer issue than a user issue. > > I don't think that it matters how you implement a grammer though. > The problem here is, that you have to define the grammer first. > > But I agree that doing it by JavaCC means is less error prone. > > > Something like http://www.lysator.liu.se/c/ANSI-C-grammar-y.html where > > different operators are grouped differently according to precedence > > would work better. > > > > As is often the case, trying to *correctly* parse a string is not > > trivial. > > > Right. Especially if there's no definition of correct... > > Morus > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Dror Matalon Zapatec Inc 1700 MLK Way Berkeley, CA 94709 http://www.fastbuzz.com http://www.zapatec.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
