Quelle est l'utilité des opérateurs infixes dans un langage de programmation?


13

Quelle est l'utilité des opérateurs infixes dans un langage de programmation? Valent-ils la complexité supplémentaire qu'ils procurent? Pouvez-vous fournir des exemples où les opérateurs infixes sont mieux adaptés au problème qui ne peut pas être traité en surchargeant simplement les opérateurs normaux?


5
Vous devez être un Lisper. Ai-je raison?
missingfaktor

@missingfaktor: À peine utilisé
Casebash

1
Comment les opérateurs infixés sont-ils liés à la surcharge des opérateurs?
Rein Henrichs

3
Il convient de noter que la majorité des langages OO (ish) populaires utilisent infix pour les noms de méthode. En effet, certains langages sont assez longs pour permettre aux méthodes "statiques" d'être écrites, disons, arg1.method(arg2)plutôt que method(arg1, arg2).
Tom Hawtin - tackline

Réponses:


16

Je pense que les opérateurs d'infixation proviennent des mathématiques.

Cette:

2 + 3 * 4

est plus lisible pour la plupart des gens que

(+ 2 (* 3 4))

parce que la plupart des gens connaissent les mathématiques.

Assez intéressant dans Haskell, vous pouvez sauter entre l'infixe et le préfixe. Ceci utilise la même fonction "(+)":

(+) 1 2
1 + 2

et cela utilise la même fonction "elem":

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

La surcharge des opérateurs normaux gère la plupart des cas
Casebash

1
@Casebash: ces opérateurs "normaux" sont parfois aussi infixés.
liori

2
Je dois être juste bizarre que, parce que je trouve (+ 1 2) beaucoup plus lisible que 1 + 2. Au moins, (+ 1 2 3 4 5)c'est mieux que 1 + 2 + 3 + 4 + 5.
Joe D

Il y a aussi RPN: pousser les éléments, puis l'opérateur.
PhiLho

@PhiLho Aussi appelé opérateurs postfix! Comme ceci: 1 2 +ou 1 2 3 4 5 +plus généralement pour le dernier cas 1 2 + 3 + 4 + 5 +. Il y a en fait un avantage astucieux pour ceux-ci en ce qu'il modélise parfaitement un système basé sur une pile et a rarement (voire jamais?) Besoin de parenthèses pour ajuster la priorité de l'opérateur.
CodexArcanum

6

Les langages informatiques sont conçus pour les humains et non pour les machines. Et les humains sont plus habitués à infixer les opérateurs que les pré ou postfixes.


6

La seule vraie raison des opérateurs d'infixes est que les humains les trouvent généralement plus faciles à lire. Cela est dû en grande partie à deux faits:

  • Nous apprenons les opérateurs infixes sous forme de mathématiques dès le plus jeune âge et les connaissons donc: 2 * 2 = 4etc.
  • Un opérateur infixe a l'avantage de séparer "visuellement" deux arguments. par exemple(some complex expression) + (some other complex expression)

D'un point de vue logique / machine, les opérateurs d'infixation n'ajoutent pas vraiment de valeur et dans certains cas sont une nuisance:

  • Vous pouvez toujours convertir infix en appel de fonction équivalent avec deux arguments - les opérateurs infix ne sont donc jamais plus que du "sucre syntaxique"
  • Infix peut être gênant lorsque vous souhaitez utiliser plus de deux paramètres. (* 1 2 3 4 5)en Lisp, par exemple, est sans doute une syntaxe beaucoup plus propre pour multiplier un ensemble de nombres.
  • Du point de vue de l'analyse, il est souvent utile de lire d'abord l'opérateur afin de savoir comment interpréter le reste de l'expression. Avec les opérateurs infixes, cela peut être beaucoup plus complexe (par exemple, vous devez conserver une pile ou quelque chose de similaire pour déterminer quel opérateur s'applique à quels arguments)
  • Dans les langages basés sur la pile / concaténatifs tels que Forth, vous voulez que l'opérateur soit poussé en dernier sur la pile, afin qu'il ait déjà ses arguments dans la bonne position. Encore une fois, enterrer l'opérateur au milieu d'une séquence de jetons ne fait que compliquer les choses.
  • Les opérateurs Infix peuvent devenir très déroutants lorsqu'ils sont surchargés - que signifie "+" lorsqu'il est appliqué à deux HashMaps par exemple? Ici, la compréhension humaine intuitive de l'opérateur infixe fonctionne contre vous car il est facile de supposer un sens qui n'était pas réellement prévu .....

Je pense que le dernier argument est faux. C'est au programmeur d'utiliser des noms sensés pour les fonctions, que ce soit en utilisant des symboles ou des lettres.
Tom Hawtin - tackline

@Tom - bien sûr, les programmeurs doivent choisir des noms raisonnables. Mais l'un des critères clés du «sensé» est «d'autres personnes peuvent-elles le comprendre intuitivement? - J'ai vu plein de cas de surcharge d'opérateur où c'est loin d'être le cas. Je ne veux pas avoir à désosser la définition délirante de quelqu'un de ce que ">> =" signifie lorsqu'elle est appliquée à un type de données arbitraire. Noms de fonction appropriés, s'il vous plaît!
mikera
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.