If you're choosing between options at runtime, you might consider
thinking about a plugin architecture instead.  Modules are pretty much
all set at link time.

Here's a simple example of the strategy:

module M = struct
  exception No_plugin
  type entry = { reg_f : int -> int }
  let current_entry : entry option = ref None
  let register e = current_entry := Some e
  let get_entry () = match !current_entry with
    | None -> raise No_plugin
    | Some e -> e
  let f x = (get_entry ()).f x
end

module M1 = struct
  let f x = x + 1
  let m1_entry = { M.reg_f = f }
  let _ = M.register m1_entry  
end

This model puts more constraints on types than using modules would,
but does have a variety of different ways to be useful.  For example,
M1 could instead of registering automatically wait until told, or M
could keep a list of registered plugins and take the first one that
"works" for an input, etc.

And finally, you may also be able to do things differently using
functors--one of which you seem to be using in your example.  Here's
an example of my idea here:

Original:

module M = if arg then M1 else M2

type t = M.t

let f = M.f
let g = M.g
...

can instead be written:

module X (M : M_T) : R_T with type t = (* something *) = struct
  (* definitions involving M *)
end

module X1 = X(M1)
module X2 = X(M2)

type t = X1.t

let f = if arg then X1.f else X2.f
let g = if arg then X1.g else X2.g

This approach is a little verbose, but should work reasonably well. 
Again, your constraint here is that X1 and X2 will have to have
identical types, not just similar types.  (And that's the real reason
that you can't do conditionals to choose one of several modules: you
can't do conditionals at runtime on types!)

John.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners