From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 02EB2BB91 for ; Sun, 9 Jan 2005 16:47:21 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j09FlKFY020233 for ; Sun, 9 Jan 2005 16:47:20 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA11967 for ; Sun, 9 Jan 2005 16:47:20 +0100 (MET) Received: from herd.plethora.net (herd.plethora.net [205.166.146.1]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j09FlHqZ020221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 9 Jan 2005 16:47:19 +0100 Received: from bhurt.plethora.net (bhurt.plethora.net [205.166.146.49]) by herd.plethora.net (8.13.1/8.12.11) with ESMTP id j09Fl5JV014713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Jan 2005 09:47:13 -0600 (CST) Date: Sun, 9 Jan 2005 09:48:38 -0600 (CST) From: Brian Hurt X-X-Sender: bhurt@localhost.localdomain To: wiedergaenger@fastmail.fm Cc: caml-list@inria.fr Subject: Re: [Caml-list] generic functions In-Reply-To: <20050109131928.GA1759@wafthrudnir> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at nez-perce with ID 41E15208.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 41E15205.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 wrote:01 ocaml:01 clos:01 ocaml:01 foo:01 foo:01 redefined:01 pointless:01 compilation:01 overloading:01 inference:01 mult:01 sig:01 val:01 X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.0 X-Spam-Level: On Sun, 9 Jan 2005 wiedergaenger@fastmail.fm wrote: > I just got from LISP to OCaml, and wondered if there is an equivalent of > generic functions from LISP (CLOS) in OCaml. In the Common Lisp Object > System methods don't belong to certain objects/classes. They are just > function specializing on the argument types. So basically I want to > write something like: > > let foo (x : int) = x*x;; > let foo (x : float) = x*.x;; > > This, obviously, will not work since foo is just redefined by the second > statement. One would think, that having methods not being belonging to > objects/classes, is rather pointless. Well 95% of the time, there is no > necessity for that. But in the other 5%, it is really helpful. > The short answer is no. For two reasons- first, Ocaml doesn't keep type information (in most cases) of data at run time, the type information is used during compilation and then tossed. Which means that Ocaml doesn't have a way at run time to tell which version of the function to call. And second, and more importantly, overloading (like you're doing above) would make type inference extremely difficult if not impossible. There are several ways to "work around" this limitation in Ocaml, depending upon what exactly you are doing. 1) Just use different functions. Do: let ifoo x = x * x;; let ffoo x = x *. x;; and just call the correct one. This is generally not as bad a solution as you might think. 2) Use variant types: type number = Int of int | Float of float;; let foo = function | Int(x) -> Int(x*x) | Float(x) -> Float(x*.x) ;; The tags in this case are the type information Ocaml would normally "throw away". 3) Use modules: module type Mult = sig type t val mul : t -> t -> t end module type Foo = sig type t val foo : t -> t end module Make(M: Mult) : Foo with type t = M.t = struct type t = M.t let foo x = M.mul x x end;; module IMult = struct type t = int let mul x y = x * y end;; module IFoo = Make(IMult);; module FMult = struct type t = float let mul x y = x *. y end module FFoo = Make(FMult); For this simple example, modules and functors are clunky- but they allow the user of your code to create new foo functions, which is usefull. With the exception of certain artificial contests (Paul Graham) I've never met a real world problem that needed overloading, or even benefitted signifigantly from overloading that didn't benefit just as much or more from one of the solutions above. Brian