From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <Andrej.Bauer@fmf.uni-lj.si>
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 discorde.inria.fr (discorde.inria.fr [192.93.2.38])
	by yquem.inria.fr (Postfix) with ESMTP id 47E4DBC0B
	for <caml-list@yquem.inria.fr>; Sat,  9 Dec 2006 12:28:34 +0100 (CET)
Received: from postar.fmf.uni-lj.si (vega.fmf.uni-lj.si [193.2.67.45])
	by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id kB9BSXFM017137
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <caml-list@yquem.inria.fr>; Sat, 9 Dec 2006 12:28:34 +0100
Received: from localhost (unknown [192.168.5.1])
	by postar.fmf.uni-lj.si (Postfix) with ESMTP id 37AD7EBA2C;
	Sat,  9 Dec 2006 12:28:33 +0100 (CET)
X-Virus-Scanned: amavisd-new at spam.fmf.uni-lj.si
Received: from postar.fmf.uni-lj.si ([192.168.5.5])
	by localhost (spam.fmf.uni-lj.si [192.168.5.1]) (amavisd-new, port 10024)
	with ESMTP id 7Nt-qnypQTuJ; Sat,  9 Dec 2006 12:35:46 +0100 (CET)
Received: from [192.168.1.100] (BSN-77-186-71.dsl.siol.net [193.77.186.71])
	by postar.fmf.uni-lj.si (Postfix) with ESMTP id 7E089DE868;
	Sat,  9 Dec 2006 12:28:31 +0100 (CET)
Message-ID: <457A9DDB.7060406@fmf.uni-lj.si>
Date: Sat, 09 Dec 2006 12:28:27 +0100
From: Andrej Bauer <Andrej.Bauer@fmf.uni-lj.si>
Reply-To: Andrej.Bauer@andrej.com
User-Agent: Thunderbird 1.5.0.7 (X11/20060927)
MIME-Version: 1.0
To: Jim Grundy <jim_grundy@ichips.intel.com>,
	caml-list@yquem.inria.fr
Subject: Re: [Caml-list] A Question About Types and Inlining
References: <4579F1A4.6080606@ichips.intel.com>
In-Reply-To: <4579F1A4.6080606@ichips.intel.com>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
X-Miltered: at discorde with ID 457A9DE1.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)!
X-Spam: no; 0.00; andrej:01 andrej:01 inlining:01 sig:01 solver:01 sig:01 bool:01 val:01 struct:01 bool:01 struct:01 solver:01 nesting:01 mli:01 abstract:01 

You can use multiple signatures and modules to combine things just the 
way you want them. For example, you could have modules and signatures 
organized as follows (I made up some types which don't really make sense 
for SAT):

(** The SAT module as seen from the outside. *)
module type SAT =
sig
   module Solver :
   sig
     type variable (* abstract *)
     type problem  (* abstract *)
     type solution = (variable * bool) list
     val solve : problem -> solution
   end

   module SomethingUseful : sig ... end
end

module Sat : SAT =
struct
   (* inside SAT all types are concrete *)

   type variable = int
   type problem = (variable * variable * variable) array
   type solution = (variable * bool) list

   module SatHelper =
   struct
     (* here is a helper module which is not even seen from outside *)
     (* it can rely on internal representation *)
     let internal_solve = ...
   end

   (* The module Solver is exported, we put in it exactly what we want
       the user to see. *)
   module Solver =
   struct
     type variable = variable
     type problem = problem
     type solution = solution
     let solve = SatHelper.internal_solve
   end

   module SomethingUseful = struct ... end
end

My point is that by nesting modules and exposing just the right amount 
of their interfaces through several different signatures, you can 
control precisely what is seen from where. There is no need to always 
realy on the simplistic view

   module    = .ml file
   signature = .mli file

which is just a convenient shortcut that works in simple examples.

Best regards,

Andrej

P.S. The example above makes it look as if you have to stick everything 
inside one huge file. That's not true, as you can use "include", as well 
as type sharing constraints ("with type1 = type2") to expose certain 
types between modules.