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=2.8 required=5.0 tests=DNS_FROM_RFC_POST,SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 8F99EBBC4 for ; Wed, 4 Mar 2009 17:40:18 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4CAOs9rknRVdmrhWdsb2JhbACUQz8BAQEKCQwHEASyFQeBAJAkAQMBA4QFBoJ9gUE X-IronPort-AV: E=Sophos;i="4.38,301,1233529200"; d="scan'208";a="36092337" Received: from mail-gx0-f171.google.com ([209.85.217.171]) by mail4-smtp-sop.national.inria.fr with ESMTP; 04 Mar 2009 17:40:17 +0100 Received: by gxk19 with SMTP id 19so6501801gxk.3 for ; Wed, 04 Mar 2009 08:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date :user-agent:cc:references:in-reply-to:content-type :content-transfer-encoding:content-disposition:message-id; bh=rGCL0MuS01IeUKx+cc5u28H7/ZxyDXjoVbTETzUwz2s=; b=ig92sVzI/SpgaL0TKzxMzbs8pQfUO2NeU/3JbjkMW22hVlHJPFSFDra0dnLc5saaKq JKGln4UIQvPXqc48F6SW42JK+R8uVxZQC+tJ1NhY7+E/QjizT/PafGZWyAx8KkTiDvCT v9C7KCe4ohL9daq4Jq9UVRdj4nfu9HV1JDL24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to :content-type:content-transfer-encoding:content-disposition :message-id; b=X4XstqK7xOQJ3afZcLT0oasflFqDseOTQElBHeo0BgVV/Yno0Z41N9mVlHloNMTeoI 2QcrpbZfGRPPC4IvVuSmp/KP/xjrNRwj1Ca1rPK173/8p1Ac2HTsPrUqn8WDuxhOTfzE mC2wmcP+sXcKdoUJxDmhC1GACj9i1tk7RVngE= Received: by 10.100.189.10 with SMTP id m10mr42444anf.138.1236184816422; Wed, 04 Mar 2009 08:40:16 -0800 (PST) Received: from ?192.168.0.102? (c-98-219-43-7.hsd1.ga.comcast.net [98.219.43.7]) by mx.google.com with ESMTPS id c9sm1952616ana.13.2009.03.04.08.40.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Mar 2009 08:40:15 -0800 (PST) From: Peng Zang Reply-To: peng.zang@gmail.com To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] stl? Date: Wed, 4 Mar 2009 11:40:12 -0500 User-Agent: KMail/1.9.9 Cc: Brian Hurt , Jon Harrop References: <91a2ba3e0903031340wcdc976cp52522eb35f7ccb73@mail.gmail.com> <200903040920.01990.peng.zang@gmail.com> In-Reply-To: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903041140.14566.peng.zang@gmail.com> X-Spam: no; 0.00; stl:01 hash:01 functors:01 haskell:01 sexp:01 sexp:01 foo:01 haskell:01 ocaml:01 peng:98 peng:98 2009:98 wrote:01 ints:01 caml-list:01 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 04 March 2009 11:14:50 am Brian Hurt wrote: > Yeah. I think of this as one of the advantages of Functors. > > Here are two real problems I've hit with type classes, in only a few weeks > banging around in Haskell. > > For example, you can't have more than one instance of a type class for any > given type. So let's say you want to have a type class for things that > can be converted to and from s-expressions, like: > data Sexp = > Atom String > > | List [ Sexp ] > > class Sexpable a where > toSexp :: a -> Sexp > fromSexp :: Sexp -> Maybe a > > So then you start throwing out the standard instances, among others, you > do one for string: > instance Sexpable String where > toSexp s = Atom s > fromSexp (Atom s) = Just s > fromSexp _ = Nothing > > and, a little while later, one for generic lists: > instance Sexpable a => Sexpable [ a ] where > toSexp xs = List $ map toSexp xs > fromSexp (List xs) = mapM fromSexp xs > fromSexp _ = Nothing > > Opps! Now you have conflicting instances for type String- one the > explicit implementation, and one via the generic list. There are kludges > to get around this, but they cause their own problems (Brian's first law > of programming: kludges multiply). A common one is to add the function > toSexpList and fromSexpList to the fundamental type class, and drop the > generic list implementation. Except now you can't simply toSexp a value > of type Map Int ([Int], Foo) despite the fact that Maps, Ints, Foos, and > tuples all have toSexp defined over them- that list in there says that you > have to pick things apart by hand, so you can call toSexpList instead of > toSexp at the right point. Yeah, I can see the problem with Haskell type classes. In OCaml though, I don't see how this is an issue. Let's say we are building the class for StringObj. We have a field for the data (type String) and now we implement the methods for working on Strings. When it comes to the sexp methods, either implementation can be used. You can choose. If the implementation is written else where and we want to use inheritance, we can inherit both implementations and the last one is the effective one. It's not a big issue. Peng -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFJrq7ufIRcEFL/JewRAi9zAJ96Ur/f79pFWJRaXGXwJMHcU1eTNgCg0rNo JPEqD48wWiD8XVaafSVwdrc= =tBvY -----END PGP SIGNATURE-----