Lambda the Ultimate

Perhaps the folks at INRIA are among those who believe that adding full user-specifiable operator overloading actually makes a language worse.

I comment that the two most popular languages for doing numerical work in (C and Fortran) don't have operator overloading either.

Well, but in C the expression "a+b" will work as expected, no matter if a/b are ints, shorts, longs, doubles, one of them may even be a pointer. So it surely does have some kind of operator overloading, it's just not available for user types, as in C++.

I admit this may be a matter of taste, but I always found those "+."-operators in Ocaml kind of annoying and was hoping they were only a temporary solution.

For instance, in Haskell "x+y" works for ints and doubles. However, it takes you a while to figure out that you need "x + (fromIntegral y)" if y is an int and x is a double while you could have just written "x+y" again in C or Perl. This doesn't seem to bother people as much.

"it takes you a while to figure out that you need 'x + (fromIntegral y)' if y is an int and x is a double"

What are you talking about? I just evaluated 2.34 + 5 in Haskell Hugs with no problem at all, just to be sure...

This is an annoyance just in OCaml as far as i've come about in languages i know...

Prelude> :t 2.34
2.34 :: (Fractional a) => a

Prelude> :t 5
5 :: (Num a) => a

Prelude> :t 2.34 + 5
2.34 + 5 :: (Fractional a) => a

Prelude> let x = 2.34
Prelude> let y = 2.34
Prelude> :t x
x :: Double
Prelude> :t y
y :: Integer
Prelude> x + y

:1:4:
    Couldn't match `Double' against `Integer'
      Expected type: Double
      Inferred type: Integer
    In the second argument of `(+)', namely `y'
    In the definition of `it': it = x + y
Prelude> x + fromIntegral y
7.34

That's because, IIRC, "5" is already (fromIntegral 5).

ML has always had a mild sense of schizophrenia, with its separate language for types, but the division is at least along a line that's natural for anyone used to static typing. Ocaml actually gives me two languages at runtime. One outside of the object system using fully generic types but no ad-hoc polymorphism (or specialization, if you prefer), and one inside the object system with ad hoc polymorphism but no generic types. The twain don't appear to ever meet in most real-world code I've seen -- most in fact tend to outright shun the 'O' of Ocaml and go functional-only. The folk wisdom has it that the OO portions of Ocaml don't perform nearly as well, though I don't know whether this is actually true or not.

I don't care too much about brain-damaged languages like C and Fortran. I don't bang rocks to start fires, and I prefer to use appropriate tools for the job. If that means I get to use '*' to multiply two vectors, that's absolutely my prerogative. Anyone ranting about how "operator overloading is evil" should probably be quizzed about multiple inheritance as well. It usually belies an affected prejudice borne more of Sun's marketing material (reminiscent of MySQL AB's early mini-polemics against transactions and foreign keys) or bad implementation (yes, C++ slicing behavior is bad, but not all languages are C++).

About multiple inheritance, I remember reading about Eiffel and at first I thought it was multiple inheritance done right, then on the web I found a paper about a problem in Eiffel with multiple inheritance, and it was really hard to understand how it worked.
Granted this was more about a 'corner case' than a general usage, but it is still a problem when a language use features that are so complex that the programmers cannot really understand how they work..

I think in some ways the cornercase errors are the worst. I mean errors that shows upp often can be learned, understod and worked around. You can come to think of them as part of the language semantic. But then the error shows upp once, and you can't recreate the error or analyze it in other ways, its verry hard to understand that it is you do that makes the error apear.

A puzzle. I do love puzzles. ;-)

Edit: added the cheerful obligatory emoticon

If that means I get to use '*' to multiply two vectors, that's absolutely my prerogative.


You probably know as well as me that, in OCaml, you don't have operator overloading, because this causes all kinds of typing problems which would in turn make the language much more complex. So be it.


On the other hand, if you really want to use '*v' to multiply two vectors

• you can easily add new operators using Camlp4 -- I personally could live with an operator '*v' or 'x' for vectors, especially if my editor had a nice way of displaying it
• I suspect that MetaOCaml-style meta-programming might provide a nice way to do "controlled" operator overloading
• if you don't care about performances, there's probably a way to do a form of operator overloading using Polymorphic Variants.

Still, you're right, this can be annoying.