From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <arnaud.spiwack@gmail.com>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr
X-Spam-Level: *
X-Spam-Status: No, score=1.0 required=5.0 tests=AWL,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 E244CBC69
	for <caml-list@yquem.inria.fr>; Thu, 18 Oct 2007 16:29:16 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAAAH8KF0dA6ba+mGdsb2JhbACOTQIBAQcCCBEWgSk
X-IronPort-AV: E=Sophos;i="4.21,295,1188770400"; 
   d="scan'208";a="18216209"
Received: from nf-out-0910.google.com ([64.233.182.190])
  by mail4-smtp-sop.national.inria.fr with ESMTP; 18 Oct 2007 16:29:16 +0200
Received: by nf-out-0910.google.com with SMTP id e27so150328nfd
        for <caml-list@yquem.inria.fr>; Thu, 18 Oct 2007 07:29:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        bh=qdzjsvfUwivq1HSFdKTaQdQ4aWax4af1Z410EidNDGU=;
        b=IJLJJkHUX6+tbO/JR7XARpYB7x4chyMQkuj3+CXrTTTTMNri75wiQO4Je5z9Vm0kZZuX0oKs3cra1tkJqlWKGaigmsO8zwNHl+6M9pOaJ1gHdSdY9sq+epQYABal8sLWTb37q+KfOvVDFeli+dxQAklHfObLIzyvBuj3ggwP7eY=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=j21o/bPnoFOrhCWIh+Ijk1NH/cxgcs5SwSWbTT39aMf6MFXOR8/EmxvPr64qHzbGuZ5zt8cWnzLWgaOEteZqz/dfLCoz0JnCuiT/3Wj5cuvgUIWV7roNNLwwjsPYt0Q20vFjikOY8U65OVZNJ8oIDdG9DbDXn9FBdc9XzbUTovA=
Received: by 10.86.54.3 with SMTP id c3mr468092fga.1192717756229;
        Thu, 18 Oct 2007 07:29:16 -0700 (PDT)
Received: from ?192.168.0.5? ( [87.88.165.197])
        by mx.google.com with ESMTPS id g8sm2074018muf.2007.10.18.07.29.12
        (version=SSLv3 cipher=RC4-MD5);
        Thu, 18 Oct 2007 07:29:13 -0700 (PDT)
Message-ID: <47176DB6.7090700@lix.polytechnique.fr>
Date: Thu, 18 Oct 2007 16:29:10 +0200
From: Arnaud Spiwack <aspiwack@lix.polytechnique.fr>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: 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>
In-Reply-To: <47176B4A.5000807@janestcapital.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: Arnaud Spiwack <arnaud.spiwack@gmail.com>
X-Spam: no; 0.00; lix:01 supertype:01 wrote:01 arnaud:01 arnaud:01 typing:01 caml-list:01 formalism:01 formalism:01 precisely:01 data:02 suggesting:02 defined:02 incomplete:03 suggestion:03 

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).


Arnaud Spiwack