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=2.8 required=5.0 tests=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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 4AF89BBAF for ; Thu, 10 Sep 2009 14:29:15 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkBAHONqErRVdvfkGdsb2JhbACSA4h9PwEBAQEJCQwHEwOvBoEqkEsBAwIEhBQF X-IronPort-AV: E=Sophos;i="4.44,364,1249250400"; d="scan'208";a="34017599" Received: from mail-ew0-f223.google.com ([209.85.219.223]) by mail3-smtp-sop.national.inria.fr with ESMTP; 10 Sep 2009 14:29:14 +0200 Received: by ewy23 with SMTP id 23so54293ewy.26 for ; Thu, 10 Sep 2009 05:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WSp1PT5MZhwTXWK7K2OpEZW84FHto7BYVgT36e0JZBI=; b=x0/NWybWmpjz21kGNDUPw+42JjWODHSkCX1uU9Q2fKI6kUtaMiyfZZuxnUS+eks3FK 8Y1TeArKcTmgpBC4SfctHXfjZRoGIC5ZvNAM10itlZlf58RtywSIFNchOD1b5asLi2x7 mmk5EUpe86tXcyiocaCIv8WAGKgy7WcrnogVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=No64MFBqY26bKjcqgU3x4Wm4rrv6/6ISv24H1yE2WcR2IuhKZi//lWaiclFhp4B25e wV2dlXtSoGx4u2HjeBudDV8M8iAr6vmK26dXEYVmTUzp9VZ9QLQ9jO/j9ZGL5MtitYno 5VmJ77ipDzTuGpJnPgZYEuUQjX4qsoPsuXFGM= MIME-Version: 1.0 Received: by 10.211.128.15 with SMTP id f15mr855038ebn.57.1252585754437; Thu, 10 Sep 2009 05:29:14 -0700 (PDT) In-Reply-To: <527cf6bc0909091240u3aa0bb40u3186457a33c0636c@mail.gmail.com> References: <4b39c80a0909091200v7ae57950q4775d4b4ed4a51b3@mail.gmail.com> <527cf6bc0909091240u3aa0bb40u3186457a33c0636c@mail.gmail.com> Date: Thu, 10 Sep 2009 14:29:14 +0200 Message-ID: <4b39c80a0909100529k6dbed781t886ea8636b7fabed@mail.gmail.com> Subject: Re: [Caml-list] Partially hiding modules in packages From: Alexey Rodriguez To: blue storm Cc: OCaml List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; clashing:01 foo:01 mli:01 syntax:01 foo:01 sig:01 val:01 val:01 foobar:01 orthogonal:01 sigs:01 mli:01 sigs:01 sig:01 clashing:01 Thanks to all who replied. I have solved my problem, but I still have a question regarding clashing type definitions. On Wed, Sep 9, 2009 at 9:40 PM, blue storm wrote= : > The problem with your packages.tgz example is that you use "module > type Foo =3D .." in the .mli. This gives the signature of a module type, > that is, it refers to a _module type_ defined in the implementation > file. > > What you want to do here is to give the signature of a _module_, not a > module types, so here is the correct syntax : > > =A0module Foo : sig > =A0 =A0type foo_t > > =A0 =A0val initial : foo_t > =A0 =A0val show : foo_t -> string > =A0end Well spotted! I already encountered this before and at the time I understood it, but I guess my brain forgot about it yesterday. Thanks for checking the files, now it works. Whether the modules are flattened in Foobar or not, I think it is orthogonal to the issue of hiding (we both use the same solution). In our case I prefer to keep the hierarchy as the packages tend to have many big modules. I also checked the source code of mlpost, thanks for the tip Jean-Christophe. This is probably the most promising solution. Now I am trying to see how much reuse of "signatures" can be achieved. Currently I defined the FOO and BAR signatures in sigs.ml. I include them in the local mli files, for example: foo.mli: > include Sigs.FOO with type foo_t =3D int > > val unsafe_modify : foo_t -> foo_t bar.mli: > include Sigs.BAR with type foo_t =3D Foo.foo_t And now the package signature is: > module Foo : Sigs.FOO > module Bar : Sigs.BAR with type foo_t =3D Foo.foo_t This works great: the representation of Foo.foo_t is hidden and the unsafe function is not visible. This requires adding the type foo_t to the signature of Bar: > module type BAR =3D sig > type bar_t > type foo_t > val initial : bar_t > val combine : bar_t -> foo_t -> foo_t > end So there is no free lunch here, I can reuse the signatures to avoid repetition but I have to introduce extra type aliases to relate signatures at include time. This could add some complexity for modules sharing many types, and now I cannot include both FOO and BAR in the same module due to clashing definitions of foo_t. The only way that comes to my mind to avoid such clashes is to invent new type alias names even though they refer to the same type. Is there a nice methodology to avoid clashing type definitions when I want to include two module (interfaces) that share types? Cheers, Alexey