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 QAA29557; Fri, 29 Nov 2002 16:26:11 +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 QAA29587 for ; Fri, 29 Nov 2002 16:26:10 +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 gATFQ9X00883; Fri, 29 Nov 2002 16:26:09 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA29638; Fri, 29 Nov 2002 16:26:08 +0100 (MET) Date: Fri, 29 Nov 2002 16:26:08 +0100 From: Xavier Leroy To: =?iso-8859-1?Q?J=F8rgen_Hermanrud_Fjeld?= Cc: ocaml Subject: Re: [Caml-list] Understanding why Ocaml doesn't support operator overloading. Message-ID: <20021129162608.B27468@pauillac.inria.fr> References: <200211282202.44717.jhf@hex.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200211282202.44717.jhf@hex.no>; from jhf@hex.no on Thu, Nov 28, 2002 at 10:02:43PM +0100 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. In technical terms, we say that the principal types property fails. This property says that the inferred type is always the "best" in the sense that it subsumes all other possible types. Its a crucial property in order to do type inference, both from a theoretical and a practical (usability) standpoint. There are many ways to go about the problem with "f" above. A simple one is to reject the definition as ambiguous, and require the programmer to disambiguate, e.g. by putting a type declaration on "x". Another equally simple is to resolve ambiguities using a default strategy, e.g. favor "int" over "float". Both ways aren't very nice, since they break the principal types property. Many type inference systems have been proposed for overloading that preserve the principal types property. The most famous example (but not the only one) is Haskell's type classes. If you look at the literature, you'll see that they all involve significant typing machinery; some even have significant impact on the design of the whole language (as in the case of Haskell). I'm not criticizing here, just pointing out that combining type inference and overloading is not a trivial extension of ML-style type inference. Hope this (partially) answers your question. - Xavier Leroy ------------------- 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