Si quiero comparar dos números (u otras entidades bien ordenadas), lo haría con x < y. Si quiero comparar tres de ellos, el estudiante de álgebra de secundaria me sugerirá intentarlo x < y < z. El programador en mí responderá con "no, eso no es válido, tienes que hacerlo x < y && y < z".

La mayoría de los lenguajes que he encontrado no parecen admitir esta sintaxis, lo cual es extraño dado lo común que es en matemáticas. Python es una notable excepción. JavaScript parece una excepción, pero en realidad es solo un desafortunado subproducto de la precedencia del operador y las conversiones implícitas; en node.js, 1 < 3 < 2evalúa a true, porque es realmente (1 < 3) < 2 === true < 2 === 1 < 2.

Entonces, mi pregunta es esta: ¿Por qué x < y < zno está comúnmente disponible en lenguajes de programación, con la semántica esperada?

Estos son operadores binarios, que cuando se encadenan, normalmente y naturalmente producen un árbol de sintaxis abstracta como:

Cuando se evalúa (lo que haces desde las hojas hacia arriba), esto produce un resultado booleano x < y, luego obtienes un error de tipo al intentar hacerlo boolean < z. Para x < y < zque funcione como lo discutió, debe crear un caso especial en el compilador para producir un árbol de sintaxis como:

No es que no sea posible hacer esto. Obviamente lo es, pero agrega cierta complejidad al analizador para un caso que realmente no aparece con tanta frecuencia. Básicamente, está creando un símbolo que a veces actúa como un operador binario y, a veces, actúa efectivamente como un operador ternario, con todas las implicaciones del manejo de errores y todo lo que ello conlleva. Eso agrega mucho espacio para que las cosas salgan mal que los diseñadores de idiomas preferirían evitar si fuera posible.

¿Por qué x < y < zno está comúnmente disponible en lenguajes de programación?

En esta respuesta concluyo que

• aunque esta construcción es trivial para implementar en la gramática de un lenguaje y crea valor para los usuarios del lenguaje,
• Las razones principales por las que esto no existe en la mayoría de los idiomas se deben a su importancia en relación con otras características y la falta de voluntad de los órganos rectores de los idiomas para
  • usuarios molestos con cambios potencialmente importantes
  • moverse para implementar la función (es decir, pereza).

Introducción

Puedo hablar desde la perspectiva de un pitonista sobre esta cuestión. Soy usuario de un idioma con esta función y me gusta estudiar los detalles de implementación del idioma. Más allá de esto, estoy algo familiarizado con el proceso de cambiar lenguajes como C y C ++ (el estándar ISO se rige por comité y versionado por año) y he visto a Ruby y Python implementar cambios importantes.

Documentación e implementación de Python

De los documentos / gramática, vemos que podemos encadenar cualquier número de expresiones con operadores de comparación:

comparison    ::=  or_expr ( comp_operator or_expr )*
comp_operator ::=  "<" | ">" | "==" | ">=" | "<=" | "!="
                   | "is" ["not"] | ["not"] "in"

y la documentación además establece:

Las comparaciones se pueden encadenar arbitrariamente, por ejemplo, x <y <= z es equivalente a x <y e y <= z, excepto que y se evalúa solo una vez (pero en ambos casos z no se evalúa en absoluto cuando se encuentra x <y ser falso)

Equivalencia lógica

Asi que

result = (x < y <= z)

es lógicamente equivalente en términos de evaluación de x, yy z, con la excepción de que yse evalúa dos veces:

x_lessthan_y = (x < y)
if x_lessthan_y:       # z is evaluated contingent on x < y being True
    y_lessthan_z = (y <= z)
    result = y_lessthan_z
else:
    result = x_lessthan_y

Nuevamente, la diferencia es que y se evalúa solo una vez con (x < y <= z).

(Tenga en cuenta que los paréntesis son completamente innecesarios y redundantes, pero los usé en beneficio de los que provienen de otros idiomas, y el código anterior es Python bastante legal).

Inspección del árbol de sintaxis abstracta analizado

Podemos inspeccionar cómo Python analiza los operadores de comparación encadenados:

>>> import ast
>>> node_obj = ast.parse('"foo" < "bar" <= "baz"')
>>> ast.dump(node_obj)
"Module(body=[Expr(value=Compare(left=Str(s='foo'), ops=[Lt(), LtE()],
 comparators=[Str(s='bar'), Str(s='baz')]))])"

Entonces podemos ver que esto realmente no es difícil de analizar para Python o cualquier otro lenguaje.

>>> ast.dump(node_obj, annotate_fields=False)
"Module([Expr(Compare(Str('foo'), [Lt(), LtE()], [Str('bar'), Str('baz')]))])"
>>> ast.dump(ast.parse("'foo' < 'bar' <= 'baz' >= 'quux'"), annotate_fields=False)
"Module([Expr(Compare(Str('foo'), [Lt(), LtE(), GtE()], [Str('bar'), Str('baz'), Str('quux')]))])"

Y, contrariamente a la respuesta actualmente aceptada, la operación ternaria es una operación de comparación genérica, que toma la primera expresión, un iterable de comparaciones específicas y un iterable de nodos de expresión para evaluar según sea necesario. Simple.

Conclusión sobre Python

Personalmente, considero que la semántica de rango es bastante elegante, y la mayoría de los profesionales de Python que conozco alentarían el uso de la función, en lugar de considerarla dañina: la semántica está claramente establecida en la documentación de buena reputación (como se señaló anteriormente).

Tenga en cuenta que el código se lee mucho más de lo que se escribe. Los cambios que mejoran la legibilidad del código deben ser aceptados, no descartados mediante la aparición de espectros genéricos de miedo, incertidumbre y duda .

Entonces, ¿por qué x <y <z no está comúnmente disponible en lenguajes de programación?

Creo que hay una confluencia de razones que se centran en la importancia relativa de la característica y el momento / inercia relativa de cambio permitidos por los gobernadores de los idiomas.

Se pueden hacer preguntas similares sobre otras características del lenguaje más importantes

¿Por qué no hay herencia múltiple disponible en Java o C #? No hay una buena respuesta aquí para ninguna de las preguntas . Quizás los desarrolladores fueron demasiado vagos, como alega Bob Martin, y las razones dadas son meras excusas. Y la herencia múltiple es un tema bastante importante en informática. Ciertamente es más importante que el encadenamiento del operador.

Existen soluciones simples

El encadenamiento de operadores de comparación es elegante, pero de ninguna manera es tan importante como la herencia múltiple. Y al igual que Java y C # tienen interfaces como solución alternativa, también lo hace cada lenguaje para comparaciones múltiples: simplemente encadena las comparaciones con "y" s booleanos, que funcionan con bastante facilidad.

La mayoría de los idiomas están regidos por un comité.

La mayoría de los idiomas están evolucionando por comité (en lugar de tener un dictador benévolo para la vida sensible como Python). Y especulo que este tema simplemente no ha visto suficiente apoyo para salir de sus respectivos comités.

¿Pueden cambiar los idiomas que no ofrecen esta función?

Si un lenguaje lo permite x < y < zsin la semántica matemática esperada, este sería un cambio radical. Si no lo permitía en primer lugar, sería casi trivial agregarlo.

Rompiendo cambios

En cuanto a los idiomas con romper cambios: hacemos idiomas de actualización a la rotura de los cambios de comportamiento - pero los usuarios tienden a no como este, especialmente los usuarios de características que pueden ser rotas. Si un usuario se basa en el comportamiento anterior de x < y < z, lo más probable es fuertemente protestar. Y puesto que la mayoría de los idiomas se rigen por el comité, no creo que se pueden conseguir mucha voluntad política para apoyar un cambio de este tipo.

Los lenguajes de computadora intentan definir las unidades más pequeñas posibles y le permiten combinarlas. La unidad más pequeña posible sería algo así como "x <y" que da un resultado booleano.

Puede solicitar un operador ternario. Un ejemplo sería x <y <z. Ahora, ¿qué combinaciones de operadores permitimos? Obviamente x> y> z o x> = y> = z o x> y> = z o tal vez x == y == z debería estar permitido. ¿Qué pasa con x <y> z? x! = y! = z? ¿Qué significa el último, x! = Y e y! = Z o que los tres son diferentes?

Ahora promociones de argumentos: en C o C ++, los argumentos serían promovidos a un tipo común. Entonces, ¿qué significa x <y <z de x es doble pero y y z son largas, largas int? ¿Los tres ascendieron al doble? ¿O y se toma como doble una vez y tanto tiempo como la otra vez? ¿Qué sucede si en C ++ uno o ambos operadores están sobrecargados?

Y por último, ¿permite algún número de operandos? ¿Como a <b> c <d> e <f> g?

Bueno, todo se vuelve muy complicado. Ahora, lo que no me importaría es que x <y <z produzca un error de sintaxis. Porque su utilidad es pequeña en comparación con el daño causado a los principiantes que no pueden entender qué hace realmente x <y <z.

En muchos lenguajes de programación, x < yes una expresión binaria que acepta dos operandos y se evalúa como un único resultado booleano. Por lo tanto, si encadena múltiples expresiones, true < zy false < zno tiene sentido, y si esas expresiones se evalúan con éxito, es probable que produzcan el resultado incorrecto.

Es mucho más fácil pensar x < yen una llamada de función que toma dos parámetros y produce un único resultado booleano. De hecho, así es como muchos idiomas lo implementan bajo el capó. Es composable, fácilmente compilable, y simplemente funciona.

El x < y < zescenario es mucho más complicado. Ahora el compilador, en efecto, tiene a la moda tres funciones: x < y, y < zy el resultado de esos dos valores anded juntos, todo ello dentro del contexto de una discutible gramática lenguaje ambiguo .

¿Por qué lo hicieron al revés? Porque es una gramática inequívoca, mucho más fácil de implementar y mucho más fácil de corregir.

La mayoría de los lenguajes principales están (al menos parcialmente) orientados a objetos. Fundamentalmente, el principio subyacente de OO es que los objetos envían mensajes a otros objetos (o a ellos mismos), y el receptor de ese mensaje tiene control total sobre cómo responder a ese mensaje.

Ahora, veamos cómo implementaríamos algo como

a < b < c

Podríamos evaluarlo estrictamente de izquierda a derecha (asociativo a la izquierda):

a.__lt__(b).__lt__(c)

Pero ahora invocamos __lt__el resultado de a.__lt__(b), que es a Boolean. Eso no tiene sentido.

Probemos asociativo correcto:

a.__lt__(b.__lt__(c))

No, eso tampoco tiene sentido. Ahora tenemos a < (something that's a Boolean).

Bien, ¿qué hay de tratarlo como azúcar sintáctico? Hagamos que una cadena de n <comparaciones envíe un mensaje n-1-ary. Esto podría significar que enviamos el mensaje __lt__a a, pasando by ccomo argumentos:

a.__lt__(b, c)

Bien, eso funciona, pero aquí hay una asimetría extraña: adecide si es menor que b. Pero bno llega a decidir si es menor que c, sino que esa decisión también es tomada por a.

¿Qué hay de interpretarlo como un mensaje n-ary enviado a this?

this.__lt__(a, b, c)

¡Finalmente! Esto puede funcionar Significa, sin embargo, que el orden de los objetos ya no es una propiedad del objeto (por ejemplo, si aes menor que bni una propiedad ani una de b), sino una propiedad del contexto (es decir this).

Desde un punto de vista convencional que parece extraño. Sin embargo, por ejemplo, en Haskell, eso es normal. Puede haber múltiples implementaciones diferentes de la Ordclase de tipos, por ejemplo, y si es o no amenor que b, depende de qué instancia de tipo de clase esté dentro del alcance.

Pero, en realidad, no es que raro en absoluto! Tanto Java ( Comparator) como .NET ( IComparer) tienen interfaces que le permiten inyectar su propia relación de orden en, por ejemplo, algoritmos de clasificación. Por lo tanto, reconocen plenamente que un pedido no es algo que se fija a un tipo, sino que depende del contexto.

Hasta donde yo sé, actualmente no hay idiomas que realicen dicha traducción. Sin embargo, existe una precedencia: tanto Ioke como Seph tienen lo que su diseñador llama "operadores trinarios": operadores que son sintácticamente binarios, pero semánticamente ternarios. En particular,

a = b

se no se interpreta como que envía el mensaje =a apasar bcomo argumento, sino más bien como enviar el mensaje =a la "corriente de tierra" (un concepto similar pero no idéntica a this) pasar ay bcomo argumentos. Entonces, a = bse interpreta como

=(a, b)

y no

a =(b)

Esto podría generalizarse fácilmente a los operadores n-arios.

Tenga en cuenta que esto es realmente peculiar de los lenguajes OO. En OO, siempre tenemos un único objeto que es en última instancia responsable de interpretar el envío de un mensaje, y como hemos visto, no es inmediatamente obvio para algo como a < b < cqué objeto debería ser.

Sin embargo, esto no se aplica a los lenguajes de procedimiento o funcionales. Por ejemplo, en Scheme , Common Lisp y Clojure , el< función es n-aria y se puede llamar con un número arbitrario de argumentos.

En particular, <hace no media "menor que", en lugar de estas funciones se interpretan de forma ligeramente diferente:

(<  a b c d) ; the sequence a, b, c, d is monotonically increasing
(>  a b c d) ; the sequence a, b, c, d is monotonically decreasing
(<= a b c d) ; the sequence a, b, c, d is monotonically non-decreasing
(>= a b c d) ; the sequence a, b, c, d is monotonically non-increasing

Es simplemente porque los diseñadores de idiomas no lo pensaron o no pensaron que fuera una buena idea. Python lo hace como lo describiste con una gramática LL (1) simple (casi).

El siguiente programa de C ++ compila con un pío de clang, incluso con advertencias configuradas al nivel más alto posible ( -Weverything):

#include <iostream>
int main () { std::cout << (1 < 3 < 2) << '\n'; }

El conjunto de compiladores de GNU, por otro lado, me advierte muy bien comparisons like 'X<=Y<=Z' do not have their mathematical meaning [-Wparentheses].

Entonces, mi pregunta es esta: ¿por qué x <y <z no está comúnmente disponible en lenguajes de programación, con la semántica esperada?

La respuesta es simple: compatibilidad con versiones anteriores. Hay una gran cantidad de código en la naturaleza que utiliza el equivalente de1<3<2 y espera que el resultado sea verdadero.

Un diseñador de idiomas solo tiene una oportunidad de hacer esto "correcto", y ese es el momento en que el idioma se diseña por primera vez. Obtener "incorrecto" inicialmente significa que otros programadores se aprovecharán rápidamente de ese comportamiento "incorrecto". Hacerlo "correcto" la segunda vez romperá esa base de código existente.