Должны ли языки запросов иметь приоритет оператора ИЛИ выше приоритета И?

Question

Традиционно большинство языков программирования имеют приоритет И выше приоритета OR, так что выражение «a OR b AND c» рассматривается как «a OR (b AND c)». После этой идеи поисковые системы и языки запросов/адресации (css, xpath, sql, ...) использовали ту же приоритетность. Разве это не ошибка?

При работе с достаточно большими данными эта приоритизация неудобна, поскольку она не позволяет создать многоразовый контекст запроса без использования круглых скобок. Удобнее создавать контекст, используя И, а затем результаты объединения в этом контексте, используя OR. Это еще более удобно, если пространство используется как оператор AND, а запятая используется как оператор OR.

Примеры: При поиске в интернете для авиабилетов в Багамах в ноябре или декабре, было бы удобнее, чтобы напечатать «Багамские о-ва авиабилете ноябрь, декабрь» вместо «авиакомпании Багамских островов билет ноябрь», «багамы авиабилете декабрь» или "авиабилет bahamas (ноябрь, декабрь)"

В CSS, если нам нужно установить стиль красного из 2 элементов, мы должны сделать это: body.app1 div.d1 td.phone span.area, body.app1 div.d1 td.fax span.area {color: red} по существу дублирующий префикс body.app1 div.d1 и suffix span.area

Если приоритет OR был выше AND, мы бы указали это в CSS: body.app1 div.d 1 td.phone, td.fax span.area {color: red}

Конечно, эта идея может быть превращена в 2 оператора ИЛИ с более высоким приоритетом, чем И, а другая с более низким, например ',' выше, ';' ниже, но во многих случаях языки не имеют запасных символов, чтобы расширить этот путь, а также существующий приоритет «,», где он используется, является низким.

Answer 1

Учитывая тот факт, что фон OR и AND является математической логикой, где они имеют четко определенный приоритет, вы не можете нарушить этот приоритет в своем дизайне, не запутывая большинство пользователей VAST.

Answer 2

Я бы предпочел бы согласованность везде, в коде, SQL, поисковых запросах, так что мне не нужно будет помнить, как это происходит в этой конкретной ситуации.

Answer 3

Я думаю, что вам не хватает точки приоритета операторов. Они есть просто для удобства программиста/писателя. Использование порядка операций делает его таким, что определенные статьи могут быть написаны без парнеров, но использование парнеров гарантирует, что читатель точно знает, что делает код, особенно когда разные языки имеют разный порядок операций.

Answer 4

Я не знаю ни одного языка, который делает это, но, возможно, это должно быть ошибкой иметь AND и OR, объединенные без круглых скобок. Это очень распространенная причина глупых ошибок.

Answer 5

Когда булевые операторы используются для объединения логических операторов, оператор «и» должен иметь приоритет над «или». Я думаю, что путаница заключается в том, что многие языки запросов неявно образуют логические утверждения от существительных, но не дают четкого представления о том, что представляют собой эти утверждения.

Например, «Foo & бар» может быть истолкован принимать только страницы, где оба из следующих условий:

1. страница содержит элемент, который соответствует «Foo».
2. Страница содержит элемент, который соответствует "bar".

Запрос «Foo | Бар» может быть истолковано оценить вышеуказанные условия и принимать любую страницу, где либо условие выполняется, но она также может быть истолковано как с участием одного условия:

1. Этот страница содержит элемент, который соответствует либо «foo», либо «bar».

Обратите внимание, что в простом «Foo | бар» Если это не имеет значения, какая интерпретация один выбрал, но, учитывая «Foo & мычание | бар», это было бы невозможно принять последнюю интерпретацию для оператора | не давая ему приоритет над оператором & если кто не интерпретируется foo & moo как означающий:

1. Эта страница содержит элемент, который соответствует как «Foo» или «мычание».

Если аргументы & включены подстановочные знаки, такая интерпретация может иметь смысл (например, foo* & *oot может означать, что один элемент должен начинаться с «Foo» и заканчивается «OOT», а не означает, что страница была есть элемент, который начинается с «foo» и, возможно, другого элемента, который заканчивается на «oot»), но без таких подстановочных знаков нет элементов, которые любая страница могла содержать, что соответствует как «foo», так и «moo», и, следовательно, нет страница может содержать такой элемент.

Возможно, решение будет заключаться в том, чтобы отдельные операторы присоединялись к элементам по сравнению с соединительными страницами. Например, если &&, &&! и || присоединиться страницы, в то время как &, &! и | присоединиться к вещам, которые будут согласованы, то foo && bar || moo && jar || quack && foo* | m* & *l &! *ll будет соответствовать каждой странице, которая содержит как «Foo» и «бар», каждую страницу, которая содержит как «мычание »и« jar », а также каждую страницу, содержащую слово« quack », а также содержит слово, начинающееся с« foo »или начинающееся с« m », заканчивается на« l »и не заканчивается символом" Л.Л.».

Answer 6

Как ни странно, в первом примере вы неявно использовать AND с более высоким приоритетом, так как

airline tickets bahama november 

, безусловно, следует понимать, как, например,

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

Это подвергает славно глупости вашего идея.

Суть в том, что всегда можно создавать запросы, которые длиннее, если приоритеты такие, как они есть, и будут короче с альтернативными приоритетами. Точно так же, как можно было бы получить арифметические выражения, которые могли бы быть написаны с меньшими скобками, если добавление имело более высокий приоритет, чем умножение. Но это само по себе не является достаточной причиной для изменения поведения.