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.
next prev 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