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 WAA28256; Sat, 30 Nov 2002 22:13:29 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA28124 for caml-list@pauillac.inria.fr; Sat, 30 Nov 2002 22:13:29 +0100 (MET) 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 LAA19470 for ; Sat, 30 Nov 2002 11:36:34 +0100 (MET) Received: from ep09.kernel.pl (ep09.kernel.pl [212.87.11.162]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id gAUAaXX27497 for ; Sat, 30 Nov 2002 11:36:33 +0100 (MET) Received: (qmail 830 invoked by uid 566); 30 Nov 2002 10:36:31 -0000 Date: Sat, 30 Nov 2002 11:24:00 +0100 From: Michal Moskal To: Mike Lin Cc: caml-list@inria.fr Subject: Re: [Caml-list] Understanding why Ocaml doesn't support operator overloading. Message-ID: <20021130102400.GA2705@roke.freak> References: <20021129172616.GC16911@roke.freak> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-PGP-Fingerprint: CF89 1B14 11BE 1CC9 2CA3 7497 5E32 69B4 BC71 B4C2 X-AntiVirus: scanned for viruses by AMaViS 0.2.1 (http://amavis.org/) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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; else 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 trivial. -- : Michal Moskal ::::: malekith/at/pld-linux.org : GCS {C,UL}++++$ a? !tv : PLD Linux ::::::: Wroclaw University, CS Dept : {E-,w}-- {b++,e}>+++ h ------------------- 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