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-30 (21:13)
From: Michal Moskal <malekith@p...>
Subject: Re: [Caml-list] Understanding why Ocaml doesn't support operator overloading.
On Fri, Nov 29, 2002 at 07:00:21PM -0500, Mike Lin wrote:
> >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? 

No. Compiler trates polymorphic types as abstract then. It need not know
what is the exact type, all it cares about is size of data, which in
case of OCaml on 32 bit machines is always 4 bytes. 

For example in:

let f g x = g x x

f ( + ) 1
f ( +. ) 1.0

There is no problem for the compiler. It can genarate code for f like:

void *f(void *(*g)(void *, void *), void *x)
	return g(x, x);

However for:

let f x = x + x

it needs to generate something like:

void *f(void *x)
	if (is_integer(x))
		return x + x;
		return box(unbox(x) +. unbox(x));
	// unbox(x) == *(double*)x
	// box(x) allocates double on the heap and returns pointer to it

and this runtime check has significant perfomance impact. I guess
Haskell does it.

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

Again: Haskell does it, so typing isn't real issue here.

I guess overloading could be resolved efficiently using some kind of
runtime code generation, in spirit of M$ ILX, but this is faaaaaar from

: Michal Moskal ::::: malekith/at/ :  GCS {C,UL}++++$ a? !tv
: PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: