caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Andrej Bauer <Andrej.Bauer@fmf.uni-lj.si>
To: Jim Grundy <jim_grundy@ichips.intel.com>, caml-list@yquem.inria.fr
Subject: Re: [Caml-list] A Question About Types and Inlining
Date: Sat, 09 Dec 2006 12:28:27 +0100	[thread overview]
Message-ID: <457A9DDB.7060406@fmf.uni-lj.si> (raw)
In-Reply-To: <4579F1A4.6080606@ichips.intel.com>

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.


  parent reply	other threads:[~2006-12-09 11:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-08 23:13 Jim Grundy
     [not found] ` <4579F655.3030307@philippewang.info>
     [not found]   ` <4579F8E1.6070604@ichips.intel.com>
2006-12-09  0:07     ` [Caml-list] " Philippe Wang
2006-12-09  0:55 ` Eric Cooper
2006-12-09  1:16   ` Philippe Wang
2006-12-09  1:31     ` Eric Cooper
2006-12-09  9:28   ` Jon Harrop
2006-12-09 11:28 ` Andrej Bauer [this message]
2006-12-09 13:12 ` Nicolas Pouillard
2006-12-10  6:27 ` Christian Stork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=457A9DDB.7060406@fmf.uni-lj.si \
    --to=andrej.bauer@fmf.uni-lj.si \
    --cc=Andrej.Bauer@andrej.com \
    --cc=caml-list@yquem.inria.fr \
    --cc=jim_grundy@ichips.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).