Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
You must be a Lisper. Am I right? – missingfaktor Oct 16 '10 at 14:39
@missingfaktor: Barely used it – Casebash Oct 17 '10 at 0:20
How are infix operators related to operator overloading? – Rein Henrichs May 26 '11 at 21:21
It's worth noting that the majority of popular OO(ish) languages use infix for method names. Indeed some languages go to some length to allows "static" methods to be written as, say, arg1.method(arg2) rather than method(arg1, arg2). – Tom Hawtin - tackline May 27 '11 at 8:34
up vote 13 down vote accepted

I think infix operators stem from mathematics.


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]
share|improve this answer
Overloading normal operators handles most cases of this – Casebash Sep 10 '10 at 12:02
@Casebash: those "normal" operators sometimes are infix too. – liori Sep 12 '10 at 14:38
I must be just weird than, because I find (+ 1 2) much more readable than 1 + 2. At the very least (+ 1 2 3 4 5) is better than 1 + 2 + 3 + 4 + 5. – Joe D Nov 1 '10 at 21:20
There is also RPN: push the elements, then the operator. – PhiLho Mar 10 '11 at 11:43
@PhiLho Also called postfix operators! Like this: 1 2 + or 1 2 3 4 5 + or more typically for the last case 1 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. – CodexArcanum Mar 15 '12 at 15:14

Computer languages are designed for humans not machines. And humans are more used to infix operators than pre or postfixes.

share|improve this answer

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 = 4 etc.
  • 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.....
share|improve this answer
I think the last argument is bogus. It's up to the programmer to use sensible names for functions, whether using symbols or letters. – Tom Hawtin - tackline May 27 '11 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! – mikera May 27 '11 at 10:10

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.