¿Deben los idiomas de consulta tener prioridad de operador O más que la prioridad de AND?

Question

Tradicionalmente, la mayoría de los lenguajes de programación tienen prioridad de Y más alta que la prioridad de O, de modo que la expresión "a OR b AND c" se trata como "a OR (b Y c)". Siguiendo esa idea, los motores de búsqueda y los lenguajes de consulta/direccionamiento (css, xpath, sql, ...) utilizaron la misma priorización. ¿No fue un error?

Cuando se trata de datos suficientemente grandes, esa priorización es inconveniente porque hace que sea imposible crear un contexto de consulta reutilizable sin el uso de paréntesis. Es más conveniente crear contexto mediante el uso de OR y luego los resultados de la unión en ese contexto mediante el uso de OR. Es aún más conveniente si se usa espacio como operador AND y la coma se usa como operador OR.

Ejemplos: Al buscar en la Internet para los billetes de avión a Bahamas en noviembre o diciembre que sería más conveniente que escribir "bahamas de billetes de avión noviembre, diciembre" en lugar de "Línea aérea Bahamas billetes de noviembre", "bahamas de billetes de avión de diciembre" o "billete de avión bahamas (noviembre, diciembre)"

En CSS si necesitamos establecer el estilo rojo de 2 elementos, tenemos que hacer eso: body.app1 div.d1 td.phone span.area, body.app1 div.d1 td.fax span.area {color: red} esencialmente el prefijo de duplicación body.app1 div.d1 y el sufijo span.area

Si la prioridad de O fuera mayor que AND, escribiríamos esto en CSS: body.app1 div.d 1 td.phone, td.fax span.area {color: red}

Por supuesto, esta idea se puede desarrollar para tener 2 operadores O uno con mayor prioridad que AND y uno con menor, por ejemplo ',' es más alto, ';' es más bajo, pero en muchos casos los idiomas no tienen símbolos de repuesto para extenderse de esa manera y también la prioridad existente de "," donde se usa es baja.

Answer 1

Teniendo en cuenta que el origen de OR y AND proviene de la lógica matemática, donde tienen una precedencia bien definida, no se puede violar esa precedencia en el diseño sin confundir a la mayoría VAST de los usuarios.

Answer 2

Prefiero tener consistencia en todas partes, en código, SQL, consultas de búsqueda, para que no tenga que recordar en qué dirección va en esta situación particular.

Answer 3

Creo que le falta el sentido de prioridad de los operadores. Están allí simplemente como una conveniencia para el programador/escritor de libros. El uso del orden de las operaciones hace que ciertas cláusulas se puedan escribir sin parens, pero el uso de parens garantiza que el lector sepa exactamente qué está haciendo el código, especialmente cuando los diferentes idiomas tienen un orden de operaciones diferente.

Answer 4

No conozco ningún lenguaje que haga esto, pero quizás debería ser un error tener AND y OR combinados sin paréntesis. Esta es una causa muy común de errores estúpidos.

Answer 5

Cuando se utilizan operadores booleanos para unir declaraciones lógicas, el operador "y" debe tener prioridad sobre "o". Creo que el punto de confusión es que muchos lenguajes de consulta implícitamente forman declaraciones lógicas a partir de sustantivos, pero no dejan en claro cuáles son esas declaraciones.

Por ejemplo, "foo & bar" podría interpretarse aceptando sólo páginas en las dos condiciones siguientes son verdaderas:

1. La página contiene un elemento que coincida con "foo".
2. La página contiene un elemento que coincide con "barra".

La consulta "foo | bar" podría ser interpretada para evaluar las condiciones anteriores y aceptar cualquier página donde cualquiera de estas condiciones es cierto, pero también podría interpretarse como que implica una única condición:

1. Este La página contiene un elemento que coincide con "foo" o "bar".

Tenga en cuenta que en la simple | caso "foo bar" que no importa qué interpretación se elegía, pero teniendo en cuenta "foo & moo | bar", que sería imposible adoptar esta última interpretación para el operador | sin darle prioridad sobre el operador & a menos que uno interpretado en el sentido de foo & moo:

1. Esta página contiene un elemento que coincide tanto con "foo" o "mu".

Si los argumentos a & comodines incluidos, tal interpretación podría ser significativo (por ejemplo foo* & *oot podría significar que un solo artículo debe comenzar con "foo" y termina con "oot", en lugar de lo que significa que la página tenía que tiene un elemento que comienza con "foo" y un elemento posiblemente diferente que termina en "oot"), pero sin tales comodines, no hay elementos que pueda contener ninguna página que coincida con "foo" y "moo", y por lo tanto no la página podría contener dicho artículo.

Quizás la solución sería tener operadores separados para unir elementos en lugar de unir páginas. Por ejemplo, si &&, &&! y || se unen a las páginas, mientras que &, &! y | se unen a las cosas que se ajustará, a continuación, foo && bar || moo && jar || quack && foo* | m* & *l &! *ll coincidiría con cada página que contiene "foo" y "bar", cada página que contiene tanto "mu "y" jar ", así como también cada página que contiene la palabra" quack "y también contiene una palabra que comienza con" foo ", o que comienza con" m ", termina con" l "y no termina con" ll ".

Answer 6

Irónicamente, en su primer ejemplo se utiliza implícitamente la AND con mayor prioridad, ya que

airline tickets bahama november 

es, sin duda, debe entenderse como, por ejemplo

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

Esto expone muy bien la estupidez de su idea.

El punto es que siempre es posible hacer consultas que son más largas si los precedences son como son, y serían más cortos con precedencias alternativas. Al igual que sería posible crear expresiones aritméticas que podrían escribirse con menos paréntesis si la adición tuviera una precedencia mayor que la multiplicación. Pero esto en sí mismo no es razón suficiente para alterar el comportamiento.