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 QAA30948; Fri, 29 Nov 2002 16:49:41 +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 QAA31270 for ; Fri, 29 Nov 2002 16:49:40 +0100 (MET) Received: from relay-2m.club-internet.fr (relay-2m.club-internet.fr [194.158.104.41]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id gATFndX02583; Fri, 29 Nov 2002 16:49:40 +0100 (MET) Received: from warp (lns02m-6-97.w.club-internet.fr [212.194.17.97]) by relay-2m.club-internet.fr (Postfix) with SMTP id 579D416C0; Fri, 29 Nov 2002 16:49:39 +0100 (CET) Message-ID: <001c01c297bf$436b7a20$4600a8c0@warp> From: "Nicolas Cannasse" To: "Xavier Leroy" , =?iso-8859-1?Q?J=F8rgen_Hermanrud_Fjeld?= Cc: "ocaml" References: <200211282202.44717.jhf@hex.no> <20021129162608.B27468@pauillac.inria.fr> Subject: Re: [Caml-list] Understanding why Ocaml doesn't support operator overloading. Date: Fri, 29 Nov 2002 16:52:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > Some time ago, when looking at Ocaml for the first time, I got > > baffled by the lack of operator overloading. I am still wondering > > why this is the case. Could someone please point me to more > > information about this? > > I remember reading something about operator overloading and type inference > > beeing hard to combine. > > I don't know how technical you'd like the answer to be, so let me > start with a simple explanation that doesn't get into all technical > details. > > The problem is indeed the combination of overloading and type > inference. The catch-22 is this: > - overloading determines the meaning of an operator from the types of > its arguments (e.g. to determine whether + is integer addition or > floating-point addition); > - type inference relies (among other things) on the fact that each > operator has a unique type to determine the types of its arguments > (e.g. if one of the arguments is a function parameter). > > If you don't see the circularity, consider > > let f x = x + x > > If "+" is overloaded on integers and on floats, you get two possible > types for f: int -> int or float -> float. None of these types is > better than the other; if the compiler commits to one of them, say > int->int, later applications of f (e.g. to a float) can be rejected. I have already seen this sample in my early caml days and there is still something I don't get. 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 ? :) Regards, Nicolas Cannasse ------------------- 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