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.0 required=5.0 tests=none 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 714CDBC69 for ; Sat, 10 Mar 2007 04:13:24 +0100 (CET) Received: from ipmail03.adl2.internode.on.net (ipmail03.adl2.internode.on.net [203.16.214.135]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l2A3DLBg014662 for ; Sat, 10 Mar 2007 04:13:23 +0100 Received: from ppp19-103.lns2.syd7.internode.on.net (HELO [192.168.1.201]) ([59.167.19.103]) by ipmail03.adl2.internode.on.net with ESMTP; 10 Mar 2007 13:43:19 +1030 X-IronPort-AV: i="4.14,269,1170595800"; d="scan'208"; a="60571496:sNHT116945388" Subject: Re: [Caml-list] Operator overloading From: skaller To: Andreas Rossberg Cc: caml-list@inria.fr In-Reply-To: <45F18B2F.20307@ps.uni-sb.de> 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> <45F18B2F.20307@ps.uni-sb.de> Content-Type: text/plain Date: Sat, 10 Mar 2007 14:13:14 +1100 Message-Id: <1173496394.14315.56.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 45F22251.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; overloading:01 0100,:01 rossberg:01 oleg's:01 ocaml:01 struct:01 struct:01 recursive:01 subtyping:01 orthogonal:01 ocaml:01 subtyping:01 syntax:01 recursive:01 haskell:01 On Fri, 2007-03-09 at 17:28 +0100, Andreas Rossberg wrote: > 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. That depends on terminology. I was thinking in C++ terms: record = struct class = struct with methods > 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. Yes, records can have state, but usually any functions stored in record fields are not bound to the state of the record. Methods of an object are bound to the state of the object. > 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. Sure, but you're missing the point. In Haskell and in Oleg's Ocaml implementation of typeclasses, a record object is like a C++ vtable. A vtable contains static function pointers which can be bound to the current object to create methods. But I'm talking about replacing this with a class object, so we're not talking about the methods binding against the typeclass datatype .. we're talking about methods bound against the typeclass itself. > > 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. I did. I said 'derived classes'. > 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). Yes, its very weak. I don't know Haskell, but in Felix I have typeclasses where I need to override the default method and I can't. I don't know if Haskell suffers this restriction, but for someone used to using C++ it shows the weakness of the typeclass/instance dichotomy immediately. I actually need to do this: typeclass container[bag,value] { virtual fold ..; // no default method } typeclass stl_container[bag,iterator,value] { inherit container[bag,value]; // "implementation inheritance" fold .. // default method } because all STL containers have a single fold function, implemented by using iterators. I need to instantiate fold in the derived typeclass stl_container, but I'm not allowed to. So what I require is a tree: container --> stl_container --> vector --> vector and the distinction between typeclasses and instances is a serious obstacle. A C++ class has no such problems: you aren't limited to defining an abstraction and one concrete instance class. Roughly, my typeclasses allow adding new methods, but you cannot override a method in a derived typeclass. > Something like the covariance problem does not occur with type classes > (or modules, for that matter) because they decouple types from > interfaces. That's right.. it only occurs when you go up to the kind level. Which occurs immediately if you want to try some dependent typing. [I'm assuming a typeclass system with multiple type parameters is required of course] -- John Skaller Felix, successor to C++: http://felix.sf.net