Re: [Caml-list] Understanding why Ocaml doesn't support operator overloading.

[Pierre Weis <pierre.weis@inria.fr>]

> > The problem is what *assembly code* should be generated for function f?
> > Code to add 2 integers or code to add 2 floats? Hmm.. we'll have a
> > problem then. Or maybe both? And choose versions of f based on type it
> > is applied to? But then consider:
> >
> > let f x1 x2 ... xn = ((x1 + x1), (x2 + x2), ..., (xn + xn))
> >
> > you need to generate 2^n versions of f. We're getting to ugly things
> > like C++ templates here.
> 
> If this is really a problem then what gets generated when you write any 
> polymorphic function at all? The proposal is to allow constrained 
> polymorphism; the polymorphism that is already in OCaml seems to 
> supersede this with regard to the above objection.
> 
> I wonder if the unification algorithm can be generalized to intersect 
> sets of allowable types instead of unifying "for all" type variables. 
> It doesn't seem too ludicrous in principle but I could easily have 
> missed some nasty corner case.
> 
> -Mike

Yes: I suspect a really nasty corner in this area. As far as I
remember, the kind of types you suggest is known as ``intersection
types'', and the type reconstruction problem for languages featuring
those types is just undecidable. The big problem with this kind of
stuff is to restrict the type schemes allowed in your type system such
that you do not fall into the undecidable general case, while still
maintaining a powerful enough type system to properly typecheck the
function double (fun x -> x + x).

Unfortunately, this far from trivial...

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners