Should query languages have priority of operator OR higher than priority of AND?

Traditionally most programming languages have priority of AND higher than priority of OR so that expression "a OR b AND c" is treated as "a OR (b AND c)". Following that idea search engines and query/addressing languages (css,xpath,sql,...) used the same prioritization. Wasn't it mistake ?

When dealing with large enough data, that prioritization is inconvenient because it makes it impossible to create reusable query context without use of parentheses. It is more convenient to create context by using AND and then union results within that contex开发者_运维技巧t by using OR. It is even more convenient if space is used as AND operator and comma is used as OR operator.

Examples: When searching the internet for airline tickets to bahamas in november or december it would be more convenient to type "airline ticket bahamas november,december" instead of "airline ticket bahamas november", "airline ticket bahamas december" or "airline ticket bahamas (november,december)"

In CSS if we need to set style red of 2 elements, we have to do that: body.app1 div.d1 td.phone span.area, body.app1 div.d1 td.fax span.area{color:red} essentially duplicating prefix body.app1 div.d1 and suffix span.area

If priority of OR was higher than AND we would write this in CSS: body.app1 div.d1 td.phone,td.fax span.area{color:red}

Of course, this idea can be developed into having 2 operators OR one with higher priority than AND and one with lower, for example ',' is higher, ';' is lower, but in many cases languages don't have spare symbols to extend that way and also existing priority of "," where it's used is low.

Considering the fact that the background of OR and AND is from mathematical logic where they have well defined precedence, you can not violate that precedence in your design without confusing a VAST majority of the users.

I'd rather have consistency everywhere, in code, SQL, search queries, so that I won't have to remember which way it goes in this particular situation.

I think that you are missing the point of the priority of operators. They are there merely as a convenience to the programmer/book writer. The use of the order of operations makes it so that certain clauses can be written without parens, but the use of parens makes sure the reader knows exactly what the code is doing, especially when different languages have different order of operations.

I don't know of any language which does this, but perhaps it should be an error to have AND and OR combined without parentheses. This is a very common cause of stupid errors.

When Boolean operators are used to join logical statements, the "and" operator should have precedence over "or". I think the point of confusion is that many query languages implicitly form logical statements from nouns but don't make clear what those statements are.

For example, "foo & bar" might be interpreted accepting only pages where both of the following are true:

1. The page contains an item that matches "foo".
2. The page contains an item that matches "bar".

The query "foo | bar" might be interpreted to evaluate the above conditions and accept any page where either condition holds true, but it could also be interpreted as involving a single condition:

1. This page contains an item that matches either "foo" or "bar".

Note that in the simple "foo | bar" case it wouldn't matter which interpretation one chose, but given "foo & moo | bar", it would be impossible to adopt the latter interpretation for the | operator without giving it priority over the & operator unless one interpreted foo & moo as meaning:

1. This page contains an item that matches both "foo" or "moo".

If the arguments to & included wildcards, such an interpretation might be meaningful (e.g. foo* & *oot might mean that a single item must start with "foo" and ends with "oot", rather than meaning that the page had to have an item that starts with "foo" and a possibly-different item that ends in "oot"), but without such wildcards, there are no items any page could contain that match both "foo" and "moo", and thus no page could contain such an item.

Perhaps the solution would be to have separate operators to join items versus joining pages. For example, if &&, &&!, and || join pages, while &, &!, and | join things to be matched, then foo && bar || moo && jar || quack && foo* | m* & *l &! *ll would match every page that contains both "foo" and "bar", every page that contains both "moo" and "jar" as well as every page which contains the word "quack" and also contains a word that starts with "foo", or that starts with "m", ends with "l", and doesn't end with "ll".

Ironically, in your first example you implicitly use the AND with higher priority, since

airline tickets bahama november

is surely to be understood like, for example

.... WHERE transport = "AIR" AND target like "%bahamas%" AND month = "Nov"

This exposes nicely the silliness of your idea.

The point is, it is always possible to come up with queries that are longer if precedences are like they are, and would be shorter with alternate precedences. Just like it would be possible to come up with arithmetic expressions that could be written with less parentheses if addition had a higher precedence than multiplication. But this in itself is no sufficient reason to alter the behaviour.