Here's what is meant by operators and methods.

Attempting to keep the questions as simple and open ended as possible, since the question is more about the conceptual nature of operators and methods NOT how a language has decided to implement them.

Proof of Concept: This example in Ruby is more of a proof of concept than anything else. EXAMPLE: In Ruby, "1+2" is equivalent to "1.+(2)", meaning the object "1" implements a method called "+" with object "2" as the method's argument.

  • 1
    It might depends on the programming language. – FrustratedWithFormsDesigner Oct 5 '11 at 15:29
  • Or at least, it depends on the context. I'm not sure that computer science has a single default definition for either term - "operator" maybe, "method" almost certainly not. Anyway, I don't think that translating operators to method (or function) calls is a general comp-sci idea. It's pretty common to handle user-defined operators that way, but I don't think that in itself makes it "computer science". – Steve314 Oct 6 '11 at 8:57

Some languages (SML of NJ comes to mind) allow you to declare functions as "infix". In this case a "function" and an "operator" are pretty much identical, differing only in notation. I can neither recall nor google up the source, but I've read an essay claiming that Combinatory Logic has, as its (philosophical) roots, the desire to make "operators" the foundation of mathematics.

I think you'll probably get a lot of bad arguments both for and against the idea of operators being identical to functions. The arguments will feel similar to arguments about "what's an object?", except that mathmatically, "function" and "operator" really are identical, while "object" doesn't have a good mathematical foundation.

  • 1
    Just being pedantic, but SML of NJ is a particular compiler for the SML language - smlnj.org – Steve314 Oct 6 '11 at 9:00

Operators are not always identical to functions, since their semantics could be significantly different from a plain function call semantics. For example, sizeof(...) operator in C does not evaluate its argument. Ternary operator (x?y:z) always evaluate only two of its arguments. Logical operators (&&, ||) may not evaluate second argument.

And even the plain arithmetic operators might have complicated implicit type casting behaviour.

For this reason, you can't define operators as functions, at least in an eager language. Lazy languages are different, but still, you won't be able to define something like sizeof(...) as a function.

  • 4
    I disagree that because the ternary operator only will evaluate two arguments it could not be a function. Consider: xpres ternary(xpres arg, xpres trueVal, xpres falseVal) { if (eval(arg) { return eval(trueVal); } else { return eval(falseVal); } } All you need is expression support. This is exclusive to operators in some languages, but available in others. – Michael K Oct 5 '11 at 16:56
  • The parentheses are not part of the sizeof operator. They are redundant most of the time, unless your argument is a type. – starblue Oct 5 '11 at 19:52
  • @Michael, eval is just another form of lazyness, which I've mentioned already. – SK-logic Oct 5 '11 at 21:36
  • sizeof could be a function if the language supported type arguments. sizeof(a) would cast a to a Type object, then the sizeof function would return x.bytes. For example. Of course you are right that this cannot be done in C. – Zan Lynx Oct 6 '11 at 0:47
  • @Zan, you're right. But the implicit casting rules and overload lookup rules would be very twisted in such a language. – SK-logic Oct 6 '11 at 6:09

At least in Haskell, an operator is a symbol function with an arity of at least 2. (Although there is an extension that lifts this restriction) You can define your own operators, overload them via type-classes, give them precedence and associativity etc... After all, by putting parenthesis around an operator, you can use it just like any other (prefix) function. You can even use an ordinary function as an operator by encapsulating it in backticks.

Here are some (silly) examples:

(.:) :: (a -> b) -> (c -> d -> a) -> (c -> d -> b)
(.:) = (.) . (.)

(§) = negate .: (*)

-- or similiar

a § b = - (a * b)

infixl 7 *
infixr 9 .:
  • 6
    What does the boobies function do? – configurator Oct 5 '11 at 16:46
  • @configurator It's also called dot according to haskell.org/haskellwiki/Pointfree. The type signature basically tells you what it does. (a -> b) means "a function that takes an a, and returns a b. (c -> d -> a) means "a function that takes a c and a d and returns an a. So f ((.) . (.)) g would take two arguments, apply g to them, then apply f to the result. – MatrixFrog Oct 5 '11 at 18:02
  • @FUZxxl IsPostfixOperators the extension you were talking about? – MatrixFrog Oct 5 '11 at 18:11
  • 1
    @MatrixFrog Yes. And BTW, you can't write it like that. It would be ((.).(.)) f g or f .: g after the definition above. – FUZxxl Oct 5 '11 at 18:20
  • 4
    LOL, more languages need boobies – FinnNk Oct 5 '11 at 21:23

It is highly dependent on language.

Most high level function languages they are identical.

For interpreted languages there is usually little difference (especially when the language allows you to write your own operators (then it is just syntactic sugar for a method call), but then an interpreted language all operators are basically method calls as the language is interpreted).

When it comes to languages like C++ the story gets more complex.

  • operators on primitive types are not like method calls.
  • operators on class types are just that: method calls.

There is important distinction as this can change the inherent expected behavior of the operator. For example the && and || opertors are shortcut operators when used on primative types. But when you override for a particular class they are now the equivalent of method calls and thus all parameters must be evaluated before the method is called and thus they are no longer short-cut operators.

When using methods (and thus class specific overloaded operators) you have specific guarantees about where the sequence points are (thus certain side effects are OK). But with normal operators there are usually no sequence points until the end of the expression (thus side effects have a much larger scope for interfering with the rest of the expression).

  • 4
    Whether the language is interpreted or compiled has nothing to do with how it treats operators and methods. – configurator Oct 5 '11 at 16:45

In addition to the other answers here, which cover a lot of good examples, here's another bit.

In C++, for example, some operators have to be defined outside of a class's definition, and are thus 'free functions' with a left-hand-side and a right-hand-side (2 arguments).

So in this case they aren't even "Methods", as they are not defined inside any class.


At least in Scala operators are functions methods. You can use a method which takes single parameter as infix operator (see A Tour of Scala: Operators and Scala for C# programmers, part 6: infix operators

  • No, they are methods. – Jörg W Mittag Oct 6 '11 at 0:36
  • @Jörg W Mittag my bad, edited – ts01 Oct 6 '11 at 8:46

First, understand that a "method" is nothing but a function. (Please do not confuse "method" with "method overloading", "method dispatch" etc. which are indeed nice language features.)

Second, understand that an operator is nothing but a function with a funny name and special support from the parser so you can write them pre-, post- or infix.

Hence, it is quite correct to say that operators are "special methods".

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