Version française
Home     About     Download     Resources     Contact us    
Browse thread
A Question About Types and Inlining
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Andrej Bauer <Andrej.Bauer@f...>
Subject: Re: [Caml-list] A Question About Types and Inlining
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.