## OCaml 3.0.9

The most recent version of Objective Caml is 3.09.0. It was released on 2005-10-27.

Some of the highlights in release 3.09 are:

• Introduction of private row types, for abstracting the row variable in object and variant types.
• Added warnings Y and Z for local variables that are bound but never used.
• More portable implementation of the -pack option to ocamlopt.

## Comment viewing options

We can start another thread to debate the perils or virtue of overloading; here I'm interested in the implementation question: Why doesn't OCaml have overloading yet? I thought it had something to do with the troublesome interaction with type inference, but I wonder what stops the INRIA team that didn't stop the creators of gcaml, Haskell, Chameleon, and System CT.

### Taste

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

or virtual function overloading? If the latter, Ocaml already has it. If the former, I doubt Ocaml will ever get it. I comment that the two most popular languages for doing numerical work in (C and Fortran) don't have operator overloading either.

### Operators in C

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.

### Minor syntax

I think one of the reasons people are annoyed so much by the "+." is because it's on the 2nd or 3rd paragraph of the official documentation and leaves a lasting impression.

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.

### bother?

"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...

### It takes you a while to figure out...

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 sens

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 corn

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.

### Great!

A puzzle. I do love puzzles. ;-)

Edit: added the cheerful obligatory emoticon

### Schizophrenia + operators

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.