Qual a utilidade dos operadores infix em uma linguagem de programação?

Qual a utilidade dos operadores infix em uma linguagem de programação? Eles valem a complexidade extra que fornecem? Você pode fornecer alguns exemplos em que os operadores infix são mais adequados para o problema que não pode ser tratado apenas sobrecarregando os operadores normais?

programming-languages syntax operators

— Casebash
fonte

Você deve ser um Lisper. Estou certo?

— missingfaktor

@missingfaktor: Mal usei

— Casebash

Como os operadores infix estão relacionados à sobrecarga do operador?

— Rein Henrichs

Vale a pena notar que a maioria das linguagens populares OO (ish) usa infix para nomes de métodos. De fato, algumas línguas se esforçam para permitir que métodos "estáticos" sejam escritos como, digamos, arg1.method(arg2)ao invés de method(arg1, arg2).

— Tom Hawtin - tackline

Respostas:

Eu acho que operadores de infix derivam da matemática.

Este:

2 + 3 * 4

é mais legível para a maioria das pessoas, do que

(+ 2 (* 3 4))

porque a maioria das pessoas está familiarizada com a matemática.

Interessante o suficiente em Haskell, você pode pular entre infix e prefixo. Isso está usando a mesma função "(+)":

(+) 1 2
1 + 2

e isso está usando a mesma função "elem":

elem 42 [1,2,42]
42 `elem` [1,2,42]

— LennyProgrammers
fonte

Sobrecarga operador normal lida com a maioria dos casos deste

— Casebash

@ Casebash: esses operadores "normais" às vezes também são infix.

— liori 12/09/10

Devo ser apenas estranho, porque acho (+ 1 2) muito mais legível do que 1 + 2. No mínimo, (+ 1 2 3 4 5)é melhor que 1 + 2 + 3 + 4 + 5.

— Joe D

Também há RPN: empurre os elementos, depois o operador.

— PhiLho

@PhiLho Também chamado de operadores postfix! Assim: 1 2 +ou 1 2 3 4 5 +mais tipicamente para o último caso 1 2 + 3 + 4 + 5 +. Na verdade, há uma vantagem bacana para aqueles que modelam perfeitamente um sistema baseado em pilha e raramente (se é que alguma vez?) Precisa de parênteses para ajustar a precedência do operador.

— CodexArcanum

As linguagens de computador são projetadas para seres humanos e não para máquinas. E os humanos estão mais acostumados a infixar operadores do que pré ou pós-correções.

— Gulshan
fonte

A única razão real para operadores de infix é que os humanos geralmente os acham mais fáceis de ler. Isso se deve em grande parte a dois fatos:

Aprendemos operadores de infix na forma de matemática desde tenra idade e, portanto, estamos familiarizados com eles: 2 * 2 = 4etc.
Um operador infix tem a vantagem de "visualmente" separar dois argumentos. por exemplo(some complex expression) + (some other complex expression)

Do ponto de vista lógico / da máquina, os operadores infix realmente não agregam valor e, em alguns casos, são um incômodo:

Você sempre pode converter de infix em uma chamada de função equivalente com dois argumentos - para que os operadores de infix nunca sejam mais que "açúcar sintático"
Infix pode ser inconveniente quando você deseja usar mais de dois parâmetros. (* 1 2 3 4 5)no Lisp, por exemplo, é sem dúvida uma sintaxe muito mais limpa para multiplicar um conjunto de números.
De uma perspectiva de análise, geralmente é útil ler primeiro o operador para que você saiba como interpretar o restante da expressão. Com operadores infix, isso pode ser muito mais complexo (por exemplo, você precisa manter uma pilha ou algo semelhante para descobrir qual operador se aplica a quais argumentos)
Em linguagens baseadas em pilha / concatenativas, como a Forth, você deseja que o operador seja pressionado por último na pilha, para que ele já tenha seus argumentos na posição correta. Novamente, enterrar o operador no meio de uma sequência de tokens apenas complica as coisas.
Os operadores de infix podem ficar muito confusos quando estão sobrecarregados - o que "+" significa quando aplicado a dois HashMaps, por exemplo? Aqui, a compreensão humana intuitiva do operador infix funciona contra você, porque é fácil assumir um significado que não foi realmente destinado ...

— Mikera
fonte

Eu acho que o último argumento é falso. Cabe ao programador usar nomes sensíveis para funções, usando símbolos ou letras.

— Tom Hawtin - decifre

@ Tom - claro, os programadores devem escolher nomes sensatos. Mas um dos principais critérios para "sensato" é "outras pessoas podem entendê-lo intuitivamente?" - Eu já vi muitos casos com sobrecarga de operador, onde isso está longe do caso. Eu não quero ter que fazer engenharia reversa da definição estranha de alguém sobre o que ">> =" significa quando aplicado a algum tipo de dados arbitrário. Nomes de funções adequados, por favor!

— Mikera #