How useful are infix operators in a programming language? Are they worth the extra complexity they provide? Can you provide any examples where infix operators are better suited to the problem that can't be handled by just overloading the normal operators?
3 Answers
I think infix operators stem from mathematics.
This:
2 + 3 * 4
is more readable to most people, than
(+ 2 (* 3 4))
because most people are familiar with mathematics.
Interesting enough in Haskell you can hop between infix and prefix. This is using the same funtion "(+)":
(+) 1 2
1 + 2
and this is using the same function "elem":
elem 42 [1,2,42]
42 `elem` [1,2,42]
answered Sep 10, 2010 at 11:50
-
-
1
-
2I must be just weird than, because I find
(+ 1 2)much more readable than1 + 2. At the very least(+ 1 2 3 4 5)is better than1 + 2 + 3 + 4 + 5.– Joe DNov 1, 2010 at 21:20 -
1
-
@PhiLho Also called postfix operators! Like this:
1 2 +or1 2 3 4 5 +or more typically for the last case1 2 + 3 + 4 + 5 +. There's actually a nifty advantage to those in that it perfectly models a stack-based system, and rarely (if ever?) needs parentheses to adjust operator precedence. Mar 15, 2012 at 15:14
Computer languages are designed for humans not machines. And humans are more used to infix operators than pre or postfixes.
The only real reason for infix operators is that humans generally find them easier to read. This is largely due to two facts:
- We learn infix operators in the form of mathematics from an early age and hence are familiar with them:
2 * 2 = 4etc. - An infix operator has the advantage of "visually" separating two arguments. e.g.
(some complex expression) + (some other complex expression)
From a logical/machine perspective, infix operators don't really add any value and in some cases are a nuisance:
- You can always convert from infix to an equivalent function call with two arguments - so infix operators are never more than "syntactic sugar"
- Infix can be inconvenient when you want to use more than two parameters.
(* 1 2 3 4 5)in Lisp for example is arguably a much cleaner syntax for multiplying a set of numbers. - From a parsing perspective, it's often useful to read the operator first so that you know how to interpret the remainder of the expression. With infix operators this can be much more complex (e.g. you have to maintain a stack or something similar to figure out which operator applies to which arguments)
- In stack-based/concatenative languages such as Forth, you want the operator to be pushed on the stack last, so that it already has its arguments in the right position. Again, burying the operator in the middle of a sequence of tokens only complicates matters.
- Infix operators can get very confusing indeed when they are overloaded - what does "+" mean when applied to two HashMaps for example? Here, the intuitive human understanding of the infix operator works against you because it's easy to assume a meaning that wasn't actually intended.....
-
I think the last argument is bogus. It's up to the programmer to use sensible names for functions, whether using symbols or letters. May 27, 2011 at 8:30
-
@Tom - sure, programmers should pick sensible names. But one of the key criteria for "sensible" is "can other people intuitively understand it?" - I've seen plenty of cases with operator overloading where this is far from the case. I don't want to have to reverse engineer someone's whacky definition of what ">>=" means when applied to some arbitrary data type. Proper function names please!– mikeraMay 27, 2011 at 10:10
arg1.method(arg2)rather thanmethod(arg1, arg2).