From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id AB25EBCAB for ; Wed, 11 May 2005 19:12:04 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j4BHC4KL012772 for ; Wed, 11 May 2005 19:12:04 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA10560 for ; Wed, 11 May 2005 19:12:03 +0200 (MET DST) Received: from triton.rz.uni-saarland.de (triton.rz.uni-saarland.de [134.96.7.25]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j4BHC31I009268 for ; Wed, 11 May 2005 19:12:03 +0200 Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.254.254]) by triton.rz.uni-saarland.de (8.12.10/8.12.10) with ESMTP id j4BHC2Qw2530418 for ; Wed, 11 May 2005 19:12:02 +0200 (CEST) Received: from mail.cs.uni-sb.de (mail.cs.uni-sb.de [134.96.254.200]) by cs.uni-sb.de (8.13.4/2005033000) with ESMTP id j4BHC1Ix021029 for ; Wed, 11 May 2005 19:12:01 +0200 (CEST) Received: from ps.uni-sb.de (grizzly.ps.uni-sb.de [134.96.186.68]) by mail.cs.uni-sb.de (8.13.4/2005033000) with ESMTP id j4BHC1ZE017772 for ; Wed, 11 May 2005 19:12:01 +0200 (CEST) X-Authentication-Warning: mail.cs.uni-sb.de: Host grizzly.ps.uni-sb.de [134.96.186.68] claimed to be ps.uni-sb.de Received: from ps.uni-sb.de (groove.ps.uni-sb.de [134.96.186.172]) by ps.uni-sb.de (8.12.10/8.12.10) with ESMTP id j4BHBxqL020038; Wed, 11 May 2005 19:11:59 +0200 Message-ID: <42823CDF.3060109@ps.uni-sb.de> Date: Wed, 11 May 2005 19:11:59 +0200 From: Andreas Rossberg User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "O'Caml Mailing List" Subject: Re: [Caml-list] Renaming structures during inclusions? References: <20050511.183319.06547596.debian00@tiscali.be> In-Reply-To: <20050511.183319.06547596.debian00@tiscali.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.1 (triton.rz.uni-saarland.de [134.96.7.25]); Wed, 11 May 2005 19:12:02 +0200 (CEST) X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.30.0.12; VDF 6.30.0.172 X-Miltered: at concorde with ID 42823CE4.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 42823CE3.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; rossberg:01 rossberg:01 caml-list:01 christophe:01 troestler:01 compiler:01 ocaml's:01 syntax:01 struct:01 struct:01 compiler:01 reordering:01 higher-order:01 higher-order:01 cheers:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: Christophe TROESTLER wrote: > > Wouldn't it be better to have a compiler switch (say "-w T/t", off by > default) to overide that behavior (new definitions override old ones > as with [open])? Of course that makes it impossible to write M1 > signature without aliasing [t] and [Std] but IMHO that's fine. Note that OCaml's type system fundamentally relies on the fact that type names cannot be shadowed in structures. > This > way, no new syntax needs to be introduced (and one is not forced to > alias modules one does not care about -- e.g. utilities). > > module M = struct > include M1 > type m1_t = M1.t > module M1Std = M1.Std > > include M2 > type m2_t = M2.t > module M2Std = M2.Std > > module Std = struct > include M1.Std > include M2.Std > end > end While your proposal probably could be made to work in this particular case - the compiler had to figure out that it can break the dependency on the first t by reordering m1_t relative to the fields from M1 in the derived signature and substituting m1_t for t in these fields, likewise for the other elements - it is *far* from obvious if and how this can be inferred in general, particularly when your modules go higher-order. I believe it would require something akin to join and meet operations on signatures, but it is known that these don't exist for some very similar systems (signatures for higher-order modules don't form a lattice). Cheers, - Andreas -- Andreas Rossberg, rossberg@ps.uni-sb.de Let's get rid of those possible thingies! -- TB