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.6 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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 56D80BBB7 for ; Thu, 14 Aug 2008 20:37:08 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkCALQXpEjRVdkPo2dsb2JhbACRQT4BAQEBAQEHBQgHEZ1uhwEBAg X-IronPort-AV: E=Sophos;i="4.32,210,1217800800"; d="scan'208";a="13998201" Received: from mail-gx0-f15.google.com ([209.85.217.15]) by mail2-smtp-roc.national.inria.fr with ESMTP; 14 Aug 2008 20:37:07 +0200 Received: by gxk8 with SMTP id 8so3660962gxk.3 for ; Thu, 14 Aug 2008 11:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=W9lFmwaYBBaSUdMsiSSiOZINZSLJsM+LFUdAXO1x0BI=; b=RH+LTVYWnoxD/s2OkwFK1Ts3V8rmENTs4Nk7edFVX+ZbiDsG0zMEw7PBxsLmCkGUqx 7aC8jggK+8IwrVFnzE+xP87k8grg2HZYrBZmyGifQ1IDRM0swAm+lcjAUH078evDWPtC Ek7dw3Q+0dx3aqP1oTBaYglHi6gVMZliKSBoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=YHmAkRTgJAlzWi6AYGCnd8Y5l+SiJn9R4DU7ownbNm2+Gj6UQfF1fxtWPGWjFmmR30 Ln6BtZc/BLR33ioR0j8G+wnWBCHYYTNVmh+VGTct//IGsN/DfvK56bQX3mez8NCiEzxD 84r82Bx6qxwVFhOOpb6kzNxIMWS8u98dCrwKY= Received: by 10.151.27.15 with SMTP id e15mr2264824ybj.41.1218739026809; Thu, 14 Aug 2008 11:37:06 -0700 (PDT) Received: by 10.151.82.11 with HTTP; Thu, 14 Aug 2008 11:37:06 -0700 (PDT) Message-ID: <9d3ec8300808141137i2b5e606fh2f4803843ef13e88@mail.gmail.com> Date: Thu, 14 Aug 2008 19:37:06 +0100 From: "Till Varoquaux" To: "Jim Farrand" Subject: Re: [Caml-list] Typeclasses in OCaml (Was: Haskell vs OCaml) Cc: "Caml Mailing List" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200808141121.25463.peng.zang@gmail.com> X-Spam: no; 0.00; ocaml:01 haskell:01 ocaml:01 inference:01 haskell:01 inference:01 didier:01 ad-hoc:01 ocaml's:01 predictable:01 bool:01 bool:01 'self:01 undecidable:01 runtime:01 Typw inference in haskell is not decideable (nor is it in ocaml when using objects) and you have to provide some type information. I would much rather trade some inference for more power in the type system (value restriction and lack of higher rank polymorphic really kill some coding styles....) but thta is a matter of taste. Didier Remy is working on ML F which should address those. On top of breaking inference type cleases come at a high run tine cost. You can regain a lot by doing ad-hoc optimizations but this is quite far from OCaml's philosophy: the compiler's optimisations (or lack thereof) are very predictable which is nice once you move out of toy programs. Till On Thu, Aug 14, 2008 at 5:04 PM, Jim Farrand wrote: > 2008/8/14 Peng Zang : > >> (=) : 'a -> 'a -> bool >> >> But instead: >> >> (=) : (#equatable as 'a) -> 'a -> bool >> >> where >> >> class type equatable = object >> method equals : 'self -> bool >> end >> >> >> This gives all the advantages of static typing and type inference and prevents >> stupid errors and it is meaningful for all types that it is implemented for. > > 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." > > 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. > > Regards, > Jim > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >