From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 7CAC6BC6B for ; Fri, 9 Mar 2007 17:28:36 +0100 (CET) Received: from triton.rz.uni-saarland.de (triton.rz.uni-saarland.de [134.96.7.25]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l29GSZI5018114 for ; Fri, 9 Mar 2007 17:28:36 +0100 Received: from uni-sb.de (uni-sb.de [134.96.7.230]) by triton.rz.uni-saarland.de (8.12.11.20060614/8.12.10) with ESMTP id l29GSYPr4020372; Fri, 9 Mar 2007 17:28:34 +0100 (CET) Received: from mail.cs.uni-sb.de (mail.cs.uni-sb.de [134.96.254.200]) by uni-sb.de (8.14.0/2007012900) with ESMTP id l29GSYZE009441; Fri, 9 Mar 2007 17:28:34 +0100 (CET) Received: from mail.ps.uni-sb.de (james.ps.uni-sb.de [134.96.186.68]) by mail.cs.uni-sb.de (8.14.0/2007012900) with ESMTP id l29GSXrq024271; Fri, 9 Mar 2007 17:28:33 +0100 (CET) Received: from groove.ps.uni-sb.de ([134.96.186.112]) by mail.ps.uni-sb.de with esmtp (Exim 4.50) id 1HPhxI-0000Ei-Fo; Fri, 09 Mar 2007 17:28:33 +0100 Message-ID: <45F18B2F.20307@ps.uni-sb.de> Date: Fri, 09 Mar 2007 17:28:31 +0100 From: Andreas Rossberg User-Agent: Thunderbird 1.5.0.5 (X11/20060812) MIME-Version: 1.0 To: skaller Cc: caml-list@inria.fr References: <20070309073658.8F020AD34@Adric.metnet.fnmoc.navy.mil> <1173438574.22738.24.camel@rosella.wigram> <45F166AA.9090005@ps.uni-sb.de> <1173452871.22738.91.camel@rosella.wigram> In-Reply-To: <1173452871.22738.91.camel@rosella.wigram> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 134.96.186.112 X-SA-Exim-Mail-From: rossberg@ps.uni-sb.de Subject: Re: [Caml-list] Operator overloading X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on mail.ps.uni-sb.de) X-AntiVirus: checked by AntiVir Milter (version: 1.1.3-1; AVE: 7.3.1.38; VDF: 6.37.1.190; host: AntiVir1) X-Miltered: at concorde with ID 45F18B34.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; rossberg:01 rossberg:01 overloading:01 oleg's:01 ocaml:01 recursive:01 subtyping:01 orthogonal:01 ocaml:01 subtyping:01 syntax:01 recursive:01 abstraction:01 haskell:01 model:01 skaller wrote: > > I'm sorry to write so poorly. This isn't the comparison I'm > drawing. > > Consider *implementing* typeclasses with records, > as in Oleg's Ocaml examples. > > Ok, now replace the records with classes. Classes > are more powerful because they provide > > (a) state > (b) inheritance etc Records and classes are not in the same category. Records and *objects* are. OTOH, objects *are* basically records, except that they usually come with more expressive typing, particularly allowing recursive types and subtyping. State is still orthogonal - records can have state, too. Classes are a mechanism for *creating* objects (and in weaker languages than OCaml, for defining subtyping relations). Take away inheritance and you are basically left with fancy syntax for a function creating a record of mutually recursive closures over some local variables. > They also don't make the weak assumption of an > abstraction (possibly with default methods as in Haskell) > and a single instantiation: in C++ at least you can > have sequence of more derived classes. Please distinguish subtyping and inheritance. Type classes can express something akin to nominal interface subtyping, e.g. class C a where m1 :: t1 class C a => D a where m2 :: t2 But it's true that they do only provide a very weak form of inheritance (via default methods). > So the type model associated with this implementation > can do more than the one just using plain records: > records aren't typeclasses, so the class based implementation > can't be compared with them: > > records classes > typeclasses ??????? I cannot make much sense of this diagram, because of the category mismatch I mentioned above. > Anyhow my ARGUMENT was actually that using classes > subsumes plain old records .. and classes are > limited by the covariance problem, so records > must be limited too. Something like the covariance problem does not occur with type classes (or modules, for that matter) because they decouple types from interfaces. A type class is merely an interface, witnessed by a record, the actual type is abstracted out. With OO, this is mingled together (an object type *is* its interface), which produces that nasty recursion where all the type problems originate. So the difference is in the way these features factorise abstraction, rather than in the intrinsic expressiveness of the underlying primitives. Operationally, you can view dictionaries as detached "vtables". This detachment allows them to be used in more flexible ways, and avoid nuisances like the binary method issue. Of course, it also makes inheritance a rather alien concept. -- Andreas Rossberg, rossberg@ps.uni-sb.de