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

Question

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

При работе с достаточно большими данными такая расстановка приоритетов неудобна, поскольку она делает невозможным создание многоразового контекста запроса без использования скобок. Более удобно создавать контекст с помощью AND, а затем объединять результаты в этом контексте с помощью OR. Еще удобнее, если в качестве оператора AND используется пробел, а в качестве оператора OR - запятая.

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

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

Запрос "foo | bar" может быть интерпретирован для оценки вышеуказанных условий и принятия любой страницы, где выполняется любое из условий, но он также может быть интерпретирован как включающий одно условие:

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

Обратите внимание, что в простом случае "foo | bar" не имеет значения, какую интерпретацию вы выбрали, но с учетом "foo & moo | bar" было бы невозможно принять последнюю интерпретацию для оператора | без отдавая ему приоритет над оператором &, если не интерпретировать foo & moo как значение:

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

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

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

Answer 6

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

airline tickets bahama november

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

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

Это хорошо раскрывает глупость твоей идеи.

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