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?

  • 6
    You must be a Lisper. Am I right? Commented Oct 16, 2010 at 14:39
  • @missingfaktor: Barely used it
    – Casebash
    Commented Oct 17, 2010 at 0:20
  • 2
    How are infix operators related to operator overloading? Commented May 26, 2011 at 21:21
  • 3
    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). Commented May 27, 2011 at 8:34

3 Answers 3


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]
  • Overloading normal operators handles most cases of this
    – Casebash
    Commented Sep 10, 2010 at 12:02
  • 1
    @Casebash: those "normal" operators sometimes are infix too.
    – liori
    Commented Sep 12, 2010 at 14:38
  • 2
    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
    Commented Nov 1, 2010 at 21:20
  • 1
    There is also RPN: push the elements, then the operator.
    – PhiLho
    Commented Mar 10, 2011 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. Commented 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 = 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.....
  • I think the last argument is bogus. It's up to the programmer to use sensible names for functions, whether using symbols or letters. Commented 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!
    – mikera
    Commented May 27, 2011 at 10:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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