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=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id EB757BC6B; Sat, 17 Mar 2007 09:14:30 +0100 (CET) Received: from smtp3-g19.free.fr (smtp3-g19.free.fr [212.27.42.29]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l2H8EUCl000635; Sat, 17 Mar 2007 09:14:30 +0100 Received: from [192.168.0.1] (rke75-3-82-229-183-156.fbx.proxad.net [82.229.183.156]) by smtp3-g19.free.fr (Postfix) with ESMTP id 4547481C2; Sat, 17 Mar 2007 09:14:30 +0100 (CET) Message-ID: <45FBA365.5060700@inria.fr> Date: Sat, 17 Mar 2007 09:14:29 +0100 From: Alain Frisch User-Agent: Icedove 1.5.0.8 (X11/20061116) MIME-Version: 1.0 To: skaller Cc: Daniel de Rauglaudre , Caml List Subject: Re: [Caml-list] ocamlbuild and automatic dependencies References: <80E2E3A7-2603-4706-8186-566C6DA14452@gmail.com> <729DDA34-5FBE-4570-B10F-B2443B58A2F1@gmail.com> <8FC891E5-C8B6-410F-B2EB-5E06594A0165@gmail.com> <20070316142205.GB28353@yquem.inria.fr> <1174090706.10421.29.camel@rosella.wigram> In-Reply-To: <1174090706.10421.29.camel@rosella.wigram> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 45FBA366.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; frisch:01 frisch:01 dependencies:01 foo:01 foo:01 functor:01 wrote:01 abstract:01 abstract:01 caml-list:01 constraint:01 constraint:01 alain:01 alain:01 modules:02 skaller wrote: > So actually, this F is distinct from Foo, even though all the > members are the same. In particular, if Foo has an abstract type t, > is F.t the same type as Foo.t? Yes, because the signature inferred for F keeps a sharing constraint t = Foo.t. But if G is some functor with an abstract type s in the result, then G(F).s and G(Foo).s are not equal (because there is no sharing constraint between modules, such as F = Foo). -- Alain