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=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id E286DBC69 for ; Thu, 18 Oct 2007 16:46:00 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOcOF0dCm3xr/2dsb2JhbACQMg X-IronPort-AV: E=Sophos;i="4.21,295,1188770400"; d="scan'208";a="3201172" Received: from janestcapital.com (HELO smtp.janestcapital.com) ([66.155.124.107]) by mail1-smtp-roc.national.inria.fr with ESMTP; 18 Oct 2007 16:46:00 +0200 Received: from [172.25.129.161] [38.96.172.125] by janestcapital.com with ESMTP (SMTPD-9.10) id A1A705A8; Thu, 18 Oct 2007 10:45:59 -0400 Message-ID: <471771A7.3010402@janestcapital.com> Date: Thu, 18 Oct 2007 10:45:59 -0400 From: Brian Hurt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arnaud Spiwack Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Smells like duck-typing References: <377673.31302.qm@web54602.mail.re2.yahoo.com> <47176B4A.5000807@janestcapital.com> <47176DB6.7090700@lix.polytechnique.fr> In-Reply-To: <47176DB6.7090700@lix.polytechnique.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam: no; 0.00; supertype:01 supertype:01 subtype:01 subtype:01 a's:01 a's:01 ocaml's:01 polymorphism:01 imho:01 wrote:01 wrote:01 arnaud:01 typing:01 caml-list:01 formalism:01 Arnaud Spiwack wrote: > Brian Hurt a écrit : > >> Dario Teixeira wrote: >> >>> Hi, >>> >>> >>> >>>> That seems backwards from the way OO inheritance is supposed to >>>> work. You don't go from a more feature-rich case to a less >>>> feature-rich case -- it's the other way around. >>>> >>> >>> >>> Of course it is -- that is precisely why inheritance is the wrong >>> formalism for my problem! What I need is a "reverse inheritance" >>> formalism, where a fully defined data structure sits at the root, >>> and whose descendants are PRUNED versions of the parent. >>> >> >> The problem with this is that it violates one of the assumptions of >> typing, that if type A is (also) a type B, than anywhere you can use >> a type B, you can also use a type A. This isn't an assumption >> limited to object oriented languages. And this isn't true in your >> example- if type A is lacking members type B has, then it's possible >> to write situations where a "real" type B can be used, but not a type >> A- just use a field of type B that type A doesn't have. >> >> I think I'd recommend rethinking your approach to the problem. > > Well, what he is suggesting is to be able to derive a supertype A > given a type B. This is not fundamentaly incorrect. However I fail to > find any reasoning where it is made use of, in usual mathematics. So I > am, personnally, a bit puzzled by the suggestion, unable to say if it > might make sense or not (method exclusion is natural in the setting of > incomplete objets or traits, but it doesn't fit the situation very > much, since it usually produces something that requires to be completed). Saying that A is a supertype of B is the equivelent of saying B is a subtype of A. Same relation, different direction. In OO lingo, how they say "B is a subtype of A" is that "B inherits from (is a subclass of) A". In either case, while all B's are A's, not all A's are B's. What he wants is a case where not all A's are B's, but because of the magic mindreading feature of the language (in conjunction with the DWIM feature of the hardware), you can treat all A's as B's, with the system magically filling in the missing values and methods. This is what the mind reading is needed for- to know how to fill in the missing values. I will note that Ocaml's row-level polymorphism allows you to invent new supertypes of a given subtype as needed (a real nice feature, IMHO). But what he's asking for is fundamentally nonsensical. Brian