From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id AA8A97ED34 for ; Wed, 18 Jul 2012 10:19:42 +0200 (CEST) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of bardou@lsv.ens-cachan.fr) identity=pra; client-ip=188.165.56.217; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="bardou@lsv.ens-cachan.fr"; x-sender="bardou@lsv.ens-cachan.fr"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of bardou@lsv.ens-cachan.fr) identity=mailfrom; client-ip=188.165.56.217; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="bardou@lsv.ens-cachan.fr"; x-sender="bardou@lsv.ens-cachan.fr"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mo3.mail-out.ovh.net) identity=helo; client-ip=188.165.56.217; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="bardou@lsv.ens-cachan.fr"; x-sender="postmaster@mo3.mail-out.ovh.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoBAL9uBlC8pTjZmWdsb2JhbABFuUoBAQEBAQgLCwcUJ4IgAQEFOEARCxgJFg8JAwIBAgFFEwgCF4dyBL4Yi0CDM4McA5s3jG8 X-IronPort-AV: E=Sophos;i="4.77,608,1336341600"; d="scan'208";a="151011843" Received: from 16.mo3.mail-out.ovh.net (HELO mo3.mail-out.ovh.net) ([188.165.56.217]) by mail4-smtp-sop.national.inria.fr with ESMTP; 18 Jul 2012 10:19:42 +0200 Received: from mail607.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo3.mail-out.ovh.net (Postfix) with SMTP id 94AE4FF9537 for ; Wed, 18 Jul 2012 10:25:06 +0200 (CEST) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 18 Jul 2012 10:19:59 +0200 Received: from unknown (HELO ?138.231.81.39?) (romain%bardou.fr@138.231.81.39) by ns0.ovh.net with SMTP; 18 Jul 2012 10:19:58 +0200 Message-ID: <500671AD.5050305@lsv.ens-cachan.fr> Date: Wed, 18 Jul 2012 10:19:57 +0200 From: Romain Bardou User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: caml-list@inria.fr X-Ovh-Mailout: 178.32.228.3 (mo3.mail-out.ovh.net) References: <355181342595769@web13h.yandex.ru> In-Reply-To: <355181342595769@web13h.yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 8191484772909242144 X-Ovh-Remote: 138.231.81.39 () X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeegkedrjeelucetufdoteggodetrfdofgetucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucenucfhrhhomheptfhomhgrihhnuceurghrughouhcuoegsrghrughouheslhhsvhdrvghnshdqtggrtghhrghnrdhfrheqnecujfgurhepkfffhfgfggfvufhfjggtgfesthejrgdttdefud X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeegkedrjeelucetufdoteggodetrfdofgetucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucenucfhrhhomheptfhomhgrihhnuceurghrughouhcuoegsrghrughouheslhhsvhdrvghnshdqtggrtghhrghnrdhfrheqnecujfgurhepkfffhfgfggfvufhfjggtgfesthejrgdttdefud X-Validation-by: bardou@lsv.ens-cachan.fr Subject: Re: [Caml-list] parametric modules file layout On 18/07/2012 09:16, Ivan wrote: > > Hello! > > I'm creating a functor named Forest that is parametrized by two modules: A - defines operations on assoc pair, and H - defines operations on hierarchical types. So I have three signatures : ASSOC, HIER, FOREST and one module Make. Each signature is rather large and needs to be defined both in mli and ml. > > I know, that with types the problem of code repetition can be solved by refactoring them in a separate module (a ml file with implicit mli). Is it a valid solution for signatures? Can I put a signature in the sig.ml file and then refer to it with ``Sig.ASSOC?'' Or maybe there're other solutions or common practices to solve such problems? > > > Thanks, in advance. > I don't think there is any problem with that solution. It's what I would do. Cheers, -- Romain