Se eu quiser comparar dois números (ou outras entidades bem ordenadas), eu o faria com x < y. Se eu quiser comparar três deles, o aluno de álgebra do ensino médio sugerirá tentar x < y < z. O programador em mim responderá com "não, isso não é válido, você precisa fazer x < y && y < z".

A maioria das linguagens que encontrei não parece suportar essa sintaxe, o que é estranho, considerando o quão comum é em matemática. Python é uma exceção notável. O JavaScript parece uma exceção, mas é realmente apenas um subproduto infeliz da precedência do operador e conversões implícitas; no node.js, 1 < 3 < 2avalia como true, porque é realmente (1 < 3) < 2 === true < 2 === 1 < 2.

Então, minha pergunta é a seguinte: por que x < y < zgeralmente não está disponível em linguagens de programação, com a semântica esperada?

Estes são operadores binários que, quando encadeados, produzem normalmente e naturalmente uma árvore de sintaxe abstrata como:

Quando avaliado (o que você faz das folhas para cima), isso produz um resultado booleano e x < y, em seguida, você recebe um erro de tipo tentando fazer boolean < z. Para x < y < zfuncionar como discutido, você deve criar um caso especial no compilador para produzir uma árvore de sintaxe como:

Não que não seja possível fazer isso. Obviamente, é, mas adiciona alguma complexidade ao analisador para um caso que não é exibido com tanta frequência. Você está basicamente criando um símbolo que às vezes age como um operador binário e, às vezes, age efetivamente como um operador ternário, com todas as implicações do tratamento de erros e tudo o que isso implica. Isso adiciona muito espaço para as coisas darem errado que os designers de linguagem preferem evitar, se possível.

Por que x < y < zgeralmente não está disponível em linguagens de programação?

Nesta resposta concluo que

• embora essa construção seja trivial de implementar na gramática de um idioma e crie valor para os usuários,
• As principais razões pelas quais isso não existe na maioria dos idiomas devem-se à sua importância em relação a outros recursos e à falta de vontade dos órgãos de governo dos idiomas em
  • chatear os usuários com possíveis alterações
  • mover para implementar o recurso (ou seja: preguiça).

Introdução

Eu posso falar da perspectiva de um pythonista sobre esta questão. Sou usuário de um idioma com esse recurso e gosto de estudar os detalhes de implementação do idioma. Além disso, eu estou um pouco familiarizado com o processo de alterar linguagens como C e C ++ (o padrão ISO é governado pelo comitê e versionado por ano).

Documentação e implementação do Python

A partir dos documentos / gramática, vemos que podemos encadear qualquer número de expressões com operadores de comparação:

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

e a documentação declara ainda:

As comparações podem ser encadeadas arbitrariamente, por exemplo, x <y <= z é equivalente a x <y y = = z, exceto que y é avaliado apenas uma vez (mas em ambos os casos z não é avaliado quando x <y é encontrado ser falso).

Equivalência Lógica

tão

result = (x < y <= z)

é logicamente equivalente em termos de avaliação de x, y, e z, com a excepção de que yé avaliado duas vezes:

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

Novamente, a diferença é que y é avaliado apenas uma vez (x < y <= z).

(Observe, os parênteses são completamente desnecessários e redundantes, mas eu os usei para o benefício de outros idiomas, e o código acima é bastante legal em Python.)

Inspecionando a árvore de sintaxe abstrata analisada

Podemos inspecionar como o Python analisa operadores de comparação encadeados:

>>> 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')]))])"

Portanto, podemos ver que isso realmente não é difícil para o Python ou qualquer outra linguagem analisar.

>>> 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')]))])"

E, ao contrário da resposta atualmente aceita, a operação ternária é uma operação de comparação genérica, que pega a primeira expressão, uma iterável de comparações específicas e uma iterável de nós de expressão para avaliar conforme necessário. Simples.

Conclusão sobre Python

Pessoalmente, acho que a semântica de alcance é bastante elegante, e a maioria dos profissionais de Python que eu conheço encorajaria o uso do recurso, em vez de considerá-lo prejudicial - a semântica é claramente declarada na documentação de boa reputação (como observado acima).

Observe que o código é lido muito mais do que está escrito. As mudanças que melhoram a legibilidade do código devem ser adotadas, sem descontar o aumento de espectros genéricos de Medo, Incerteza e Dúvida .

Então, por que x <y <z normalmente não está disponível nas linguagens de programação?

Eu acho que há uma confluência de razões que se concentram na importância relativa do recurso e no momento / inércia de mudança permitidos pelos governadores das línguas.

Perguntas semelhantes podem ser feitas sobre outros recursos de idioma mais importantes

Por que a herança múltipla não está disponível em Java ou C #? Não há uma boa resposta aqui para qualquer uma das perguntas . Talvez os desenvolvedores tenham sido preguiçosos, como Bob Martin alega, e as razões apresentadas são apenas desculpas. E herança múltipla é um tópico bastante grande na ciência da computação. É certamente mais importante que o encadeamento do operador.

Soluções alternativas simples

O encadeamento do operador de comparação é elegante, mas não é tão importante quanto a herança múltipla. E assim como Java e C # têm interfaces como solução alternativa, todas as linguagens para várias comparações - você simplesmente encadeia as comparações com "e" s booleanos, o que funciona com bastante facilidade.

A maioria dos idiomas é governada por comitê

A maioria das línguas está evoluindo por comitê (em vez de ter um ditador benevolente sensato para a vida como o Python). E especulo que esse assunto não tenha recebido apoio suficiente para sair de seus respectivos comitês.

Os idiomas que não oferecem esse recurso podem mudar?

Se uma linguagem permitir x < y < zsem a semântica matemática esperada, isso seria uma mudança radical. Se não o permitisse, seria quase trivial adicionar.

Quebrando mudanças

Em relação aos idiomas com alterações de quebra: atualizamos os idiomas com mudanças de comportamento - mas os usuários tendem a não gostar disso, principalmente os usuários de recursos que podem estar com problemas. Se um usuário confiar no comportamento anterior de x < y < z, provavelmente protestaria em voz alta. E como a maioria das línguas é governada por um comitê, duvido que tenhamos muita vontade política para apoiar essa mudança.

As linguagens de computador tentam definir as menores unidades possíveis e permitem combiná-las. A menor unidade possível seria algo como "x <y", que fornece um resultado booleano.

Você pode solicitar um operador ternário. Um exemplo seria x <y <z. Agora, quais combinações de operadores permitimos? Obviamente x> y> z ou x> = y> = z ou x> y> = z ou talvez x == y == z deve ser permitido. E quanto a x <y> z? x! = y! = z? O que o último significa, x! = Ye y = z ou que todos os três são diferentes?

Agora promoções de argumento: em C ou C ++, os argumentos seriam promovidos para um tipo comum. Então, o que x <y <z significa x é o dobro, mas y e z são long int longo? Todos os três promovidos para dobrar? Ou y é considerado o dobro uma vez e o tempo inteiro na outra vez? O que acontece se em C ++ um ou ambos os operadores estiverem sobrecarregados?

E por último, você permite algum número de operandos? Como a <b> c <d> e <f> g?

Bem, tudo fica muito complicado. Agora, o que eu não me importaria é que x <y <z produza um erro de sintaxe. Porque a utilidade disso é pequena em comparação com o dano causado aos iniciantes que não conseguem descobrir o que x <y <z realmente faz.

Em muitas linguagens de programação, x < yé uma expressão binária que aceita dois operandos e avalia como um único resultado booleano. Portanto, se encadear várias expressões true < ze false < znão fizer sentido, e se essas expressões forem avaliadas com êxito, é provável que produzam o resultado errado.

É muito mais fácil pensar x < yem uma chamada de função que usa dois parâmetros e produz um único resultado booleano. De fato, é quantas línguas o implementam sob o capô. É comporável, facilmente compilável e simplesmente funciona.

O x < y < zcenário é muito mais complicado. Agora o compilador, com efeito, tem de moda três funções: x < y, y < zeo resultado desses dois valores anded juntos, tudo dentro do contexto de um indiscutivelmente gramática linguagem ambígua .

Por que eles fizeram o contrário? Porque é uma gramática inequívoca, muito mais fácil de implementar e muito mais fácil de corrigir.

A maioria das linguagens convencionais é (pelo menos parcialmente) orientada a objetos. Fundamentalmente, o princípio subjacente do OO é que os objetos enviam mensagens para outros objetos (ou eles mesmos), e o destinatário dessa mensagem tem controle total sobre como responder a essa mensagem.

Agora, vamos ver como implementaríamos algo como

a < b < c

Poderíamos avaliá-lo estritamente da esquerda para a direita (associativo da esquerda):

a.__lt__(b).__lt__(c)

Mas agora chamamos __lt__o resultado de a.__lt__(b), que é a Boolean. Isso não faz sentido.

Vamos tentar associativamente:

a.__lt__(b.__lt__(c))

Nah, isso também não faz sentido. Agora nós temos a < (something that's a Boolean).

Ok, que tal tratá-lo como açúcar sintático. Vamos fazer uma cadeia de n <comparações enviar uma mensagem n-1-ária. Isso pode significar que enviamos a mensagem __lt__para a, passando be ccomo argumentos:

a.__lt__(b, c)

Ok, isso funciona, mas há uma estranha assimetria aqui: adecide se é menor que b. Mas bnão decide se é menor do que c, ao contrário, essa decisão também é tomada por a.

Que tal interpretá-lo como uma mensagem n-ária enviada para this?

this.__lt__(a, b, c)

Finalmente! Isso pode funcionar. Isso significa, no entanto, que a ordenação de objetos não é mais uma propriedade do objeto (por exemplo, se aé menor do que bnão é nem uma propriedade de anem de b), mas sim uma propriedade do contexto (ie this).

Do ponto de vista convencional, isso parece estranho. No entanto, por exemplo, em Haskell, isso é normal. Pode haver várias implementações diferentes da Ordclasse de tipo, por exemplo, e se é ou não amenor b, depende de qual instância da classe de tipo está no escopo.

Mas, na verdade, não é que estranho em tudo! Java ( Comparator) e .NET ( IComparer) têm interfaces que permitem injetar sua própria relação de pedidos em, por exemplo, algoritmos de classificação. Assim, eles reconhecem plenamente que uma ordem não é algo que é fixo a um tipo, mas depende do contexto.

Até onde eu sei, atualmente não há idiomas que realizem essa tradução. Há uma precedência, no entanto: tanto a Ioke quanto a Seph têm o que seu designer chama de "operadores trinários" - operadores que são sintaticamente binários, mas semanticamente ternários. Em particular,

a = b

não é interpretado como enviando a mensagem =para apassar bcomo argumento, mas como enviando a mensagem =para a "Base atual" (um conceito semelhante, mas não idêntico a this) passando ae bcomo argumentos. Então, a = bé interpretado como

=(a, b)

e não

a =(b)

Isso poderia ser facilmente generalizado para operadores n-ários.

Observe que isso é realmente peculiar aos idiomas OO. No OO, sempre temos um único objeto que é responsável por interpretar o envio de uma mensagem e, como vimos, não é imediatamente óbvio para algo como a < b < cqual objeto deve ser.

Isso não se aplica a linguagens procedurais ou funcionais. Por exemplo, em Scheme , Common Lisp e Clojure , a <função é n-ária e pode ser chamada com um número arbitrário de argumentos.

Em particular, <faz não significa "menos que", em vez estas funções são interpretados de forma ligeiramente 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

É simplesmente porque os designers da linguagem não pensaram nisso ou não acharam uma boa ideia. O Python faz isso como você descreveu com uma gramática simples (quase) LL (1).

O programa C ++ a seguir é compilado com nary peep from clang, mesmo com avisos definidos no nível mais alto possível ( -Weverything):

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

O conjunto de compiladores gnu, por outro lado, me adverte muito bem comparisons like 'X<=Y<=Z' do not have their mathematical meaning [-Wparentheses].

Então, minha pergunta é a seguinte: por que x <y <z normalmente não está disponível em linguagens de programação, com a semântica esperada?

A resposta é simples: compatibilidade com versões anteriores. Existe uma grande quantidade de código na natureza que usa o equivalente 1<3<2e espera que o resultado seja verdadeiro.

Um designer de linguagem tem apenas uma chance de fazer isso "certo", e esse é o momento em que a linguagem é projetada pela primeira vez. Entendê-lo "errado" inicialmente significa que outros programadores tirarão vantagem rapidamente desse comportamento "errado". Colocá-lo "certo" na segunda vez quebrará essa base de código existente.