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
Type Inference and Overloading
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2006-04-10 (14:43)
From: Tom_Primožič <tom.primozic@g...>
Subject: Re: [Caml-list] Type Inference and Overloading
On 10/04/06, Brian Hurt <> wrote:
> > a : int -> float -> int
> > a : float -> int -> int
> I'm not sure there is one- in fact, I don't think there is.  Consider if I
> have the following case as above, and then I type:
> let g = a;;
> what's the type of g?  Is it int -> float -> int or float -> int -> int?

 Hm... I definitely agree that there is no way to find out the type of g in
this case, there do in fact exist 3 ways of how to deal with it:

   1. reject it (i believe this is the "right" way),
   2. have the compiler automatically overload value g, producing two
   functions, or
   3. make one value of a the /default/ value and use the type of that

As a more general rule, how I deal with overloading in Ocaml is to use
> modules and functors.

But I fear you might have misunderstood myself. I am in no way trying either
to convince anyone to implement overloading in OCaml nor saying that there
are no (useful) alternatives. During my quest I have scanned many threads of
this list over and over, and I know that any such suggestions and complaints
are dealt with in a pretty harsh way.

I am young and naive and full of idealistic illusions. So I believe in
overloading. As a great tool for the user. (Haskell's type classes are just
as irritating as the 1.5 + 0. type error, if you ask me.)

My point was, that in cases that function actually DO have a non-ambiguous
type (f1 : float -> int -> int, f1 : int -> int -> float -> int), while it
is quite easy for human to infer it, it (seems) extremely hard for a machine
to do so. Thus I am looking for a (hopefully cheap) mechanism to infer the
types correctly in such cases. I will deal with ambiguities in another way.