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. 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. > > 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. 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]
