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

[Mike Lin <mikelin@MIT.EDU>]

> 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

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