From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA29107; Sat, 30 Nov 2002 22:37:22 +0100 (MET)
X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA28991 for <caml-list@pauillac.inria.fr>; Sat, 30 Nov 2002 22:37:21 +0100 (MET)
Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35])
	by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id gAULarX08973;
	Sat, 30 Nov 2002 22:36:53 +0100 (MET)
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA29169; Sat, 30 Nov 2002 22:36:52 +0100 (MET)
From: Pierre Weis <pierre.weis@inria.fr>
Message-Id: <200211302136.WAA29169@pauillac.inria.fr>
Subject: Re: [Caml-list] Understanding why Ocaml doesn't support operator overloading.
In-Reply-To: <20021129172616.GC16911@roke.freak> from Michal Moskal at "Nov 29, 102 06:26:16 pm"
To: malekith@pld-linux.org (Michal Moskal)
Date: Sat, 30 Nov 2002 22:36:52 +0100 (MET)
Cc: warplayer@free.fr, caml-list@inria.fr
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-caml-list@pauillac.inria.fr
Precedence: bulk

> On Fri, Nov 29, 2002 at 04:52:03PM -0000, Nicolas Cannasse wrote:
> > 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 ? :)
> 
> 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.
> 
> There is third answer: generate code that checks if it's passed int or
> float. But this has very significant perfomance impact.
> 
> -- 
> : Michal Moskal ::::: malekith/at/pld-linux.org :  GCS {C,UL}++++$ a? !tv
> : PLD Linux ::::::: Wroclaw University, CS Dept :  {E-,w}-- {b++,e}>+++ h
> -------------------

There a fourth answer, more efficient than those approches, that we
call generic flows. See Jun's thesis for more detailed explanation...

Hope this helps,

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