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=1.9 required=5.0 tests=AWL,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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id C02EDBB84 for ; Thu, 14 Aug 2008 19:13:46 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkCAEEEpEjRVZKxlGdsb2JhbACRQT4BAQEBCQMKBxEDnTmGfwECgx0 X-IronPort-AV: E=Sophos;i="4.32,210,1217800800"; d="scan'208";a="15997946" Received: from wa-out-1112.google.com ([209.85.146.177]) by mail3-smtp-sop.national.inria.fr with ESMTP; 14 Aug 2008 19:13:45 +0200 Received: by wa-out-1112.google.com with SMTP id j4so272923wah.3 for ; Thu, 14 Aug 2008 10:13:44 -0700 (PDT) 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=yb/vcay0oK5JGlSotpK+Pm8BU7RqejZ1PjT7HmERoUk=; b=Bg9GYY8kXDlAkh7qQ+iYeJjAGgWH9lEE4fDOTPiYMq7/t3y4DvjL7Sk8zD1VTUj60b dzkZQGl8MiEWI8sTDC3F9EYuaon8Iiw71QJW1s/S/Fmg1BdjdbKqNB5Gthe1UxieJDXh 60HJDcbQr4iVP5zyi6piUYIpAj7bzEPTQYWhU= 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=ORKm74gR4Q/mCSe31Imh1Zl0Z4+1TTiyge4lJ2EA9yslTl1Q8JdakyIRiWHPZrlM5q LZlTcsT0NUWHMAEveJ/+AcRvqryF2jJH+lx7/mx+SVY5TC1aqxvFEnsyIGxEDO4Oo0IV 8FRw6ogP83GcfwQUxDO9bGpcnB6z7PREGUvWc= Received: by 10.114.157.1 with SMTP id f1mr1510950wae.14.1218734024440; Thu, 14 Aug 2008 10:13:44 -0700 (PDT) Received: from lawn-143-215-204-204.lawn.gatech.edu ( [143.215.204.204]) by mx.google.com with ESMTPS id 4sm947239yxd.2.2008.08.14.10.13.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 14 Aug 2008 10:13:43 -0700 (PDT) From: Peng Zang Reply-To: peng.zang@gmail.com To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Typeclasses in OCaml (Was: Haskell vs OCaml) Date: Thu, 14 Aug 2008 13:13:39 -0400 User-Agent: KMail/1.9.7 Cc: "Jim Farrand" References: <200808141121.25463.peng.zang@gmail.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808141313.42254.peng.zang@gmail.com> X-Spam: no; 0.00; ocaml:01 haskell:01 ocaml:01 hash:01 undecidable:01 haskell:01 typeclass:01 camlp:01 runtime:01 subclassing:01 zaw:01 peng:98 peng:98 blown:98 polymorphic:01 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 14 August 2008 12:04:23 pm Jim Farrand wrote: > This doesn't answer my question at all. :) > > Is there any theoretical reason they couldn't added? The kind of > answer I'm looking for is "There is no theoretical reason why not", or > "This is impossible as it would cause typing in OCaml to become > undecidable, due to interactions with other features of the OCaml type > system which aren't present in Haskell." Oh yeah... oops. But to answer your question, it appears to be "yes you can": http://okmij.org/ftp/ML/ML.html#typeclass It's not pretty as you have to pass the dictionary by hand, but perhaps some camlp4 magic could easy that. Also, the example given is of rather simple type classes, I'm not sure about the full blown thing. > Though, to address your solution, I am of course aware of it, but it > has what seem like big disadvantages: > > 1. Every value in OCaml would then have to be an object > 2. Every comparison now requires a relatively expensive dynamic > dispatch, when the correct function could be determined at runtime. > 3. If I add a new operator that wasn't thought of by the language > implementors, it can't be easily added to primitive values, without > either subclassing all of them, or changing the definition in the > standard library to add the new method. 1 & 2 are performance concerns that can be addressed as follows: Let's still have polymorphic operators like (=) and "compare". They will perform their normal operation on basic types. On objects, they will call the object's appropriate method. I have implemented this approach and use it in my own code. It let's me avoid wrapping everything in an object which lets me avoid a lot of dynamic dispatches. (the dispatches are cached so its cost is further diluted) I don't know what to do about 3. I haven't encountered it thus far. Actually, I don't know how type classes help you out here. Wouldn't you still have to modify the type definition of Ints and Floats and whatever other standard type to add the new operation? Peng -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFIpGfGfIRcEFL/JewRAmpDAJ4jfgYg0RsBw31Zaw7uDBf9UsqW8wCglk2n IdeareWjcj7t1lbnXY8k/S8= =9s95 -----END PGP SIGNATURE-----