Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Understanding why Ocaml doesn't support operator overloading.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-11-29 (15:49)
From: Nicolas Cannasse <warplayer@f...>
Subject: Re: [Caml-list] Understanding why Ocaml doesn't support operator overloading.
> > Some time ago, when looking at Ocaml for the first time, I got
> > baffled by the lack of operator overloading. I am still wondering
> > why this is the case.  Could someone please point me to more
> > information about this?
> > I remember reading something about operator overloading and type
> > beeing hard to combine.
> I don't know how technical you'd like the answer to be, so let me
> start with a simple explanation that doesn't get into all technical
> details.
> The problem is indeed the combination of overloading and type
> inference.  The catch-22 is this:
> - overloading determines the meaning of an operator from the types of
>   its arguments (e.g. to determine whether + is integer addition or
>   floating-point addition);
> - type inference relies (among other things) on the fact that each
>   operator has a unique type to determine the types of its arguments
>   (e.g. if one of the arguments is a function parameter).
> If you don't see the circularity, consider
>         let f x = x + x
> If "+" is overloaded on integers and on floats, you get two possible
> types for f: int -> int or float -> float.  None of these types is
> better than the other; if the compiler commits to one of them, say
> int->int, later applications of f (e.g. to a float) can be rejected.

I have already seen this sample in my early caml days and there is still
something I don't get.
Of course the ML type system relies on type inference and need do choose the
"best available" type but what if we enrich the type system with an "OR"
operator ? Then if (+) is overloaded on floats, you'll get :

f :  int -> int OR float -> float
or something like a type constraint :   f : 'a -> 'a where 'a in [int;float]

This approach seems trivial to me, but I really can understand that this
require a lot of addins in the typing algorithms & theory. BTW, does one of
the upper approach has already been discussed ? any paper on it ? any
countersample that will make me feel stupid ? :)

Nicolas Cannasse

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: