Thanks for all the helpful replies.

On Thu, Feb 23, 2012 at 10:05 AM, Gabriel Scherer <gabriel.scherer@gmail.com
> wrote:

> Apologies for muddling the water here: I'm not a module system expert
> (but working on it;) and my description was not technically accurate.
> Thanks Andreas and Jacques for the correction.
>
> In the meantime, here is a nicer workaround for you Ashish:
>
>  (* instead of representing the signature of MapLabels below directly,
>     we build a functor that returns the image signature *)
>  module MAPLABELS (Ord : BatInterfaces.OrderedType) = struct
>    module M = BatMap.Make(Ord)
>    module type S = module type of M.Labels
>  end
>
>  module MapLabels = struct
>    module Make (Ord : BatInterfaces.OrderedType) : MAPLABELS(Ord).S =
> struct
>      module M = BatMap.Make(Ord)
>      include M.Labels
>    end
>  end
>
>  module Test = MapLabels.Make(String)
>  module MS = BatMap.Make(String)
>  (* Test.t and MS.t are compatible, thanks to applicative functors *)
>  let test = Test.add ~key:"foo" ~data:1 MS.empty
>
> On Thu, Feb 23, 2012 at 12:17 AM, Jacques Garrigue
> <garrigue@math.nagoya-u.ac.jp> wrote:
> > On 2012/02/23, at 3:49, Andreas Rossberg wrote:
> >
> >> On Feb 22, 2012, at 18.24 h, Gabriel Scherer wrote:
> >>>> [A(B)] and  [A.B] are syntacticly valid module_expr's but
> >>>> [A(B).C] isn't. Is this because of an inherent limitation in the
> >>>> module system?
> >>>
> >>> I believe so. When you apply a functor, you may get fresh types as a
> >>> result -- the generative (abstract, algebraic) types of the functor
> >>> image. If you write `module M = A(B)`, the fresh types have a clear
> >>> identity: M.t, M.q etc; similarly if you pass A(B) to a functor with
> >>> formal parameter X, it is X.t, X.q etc. But if you write `module M =
> >>> A(B).C`, there is no syntactic way to name the fresh types generated
> >>> by the functor application; in particular, naming them A(B).t would be
> >>> incorrect -- because you could mix types of different applications.
> >>>
> >>> For example, what would be the signature of A(B).C with:
> >>>
> >>> module B = struct end
> >>> module A(X : sig end) = struct
> >>>   type t
> >>>   module C = struct type q = t end
> >>> end
> >>>
> >>> ?
> >>
> >> Are you perhaps thinking of SML-style generative functors here? Because
> with Ocaml's applicative functors F(A) in fact always returns the same
> abstract types, and you _can_ actually refer to types via the notation
> F(A).t ;-)
> >
> > This is not strictly correct, because of the possibility of avoidance.
> > I.e. you are allowed to apply a functor to a structure rather than a
> path, and in that case the behavior of the functor becomes generative,
> > so the problem described by Gabriel really applies in that case.
> >
> > Going back to the question of "module type of", it is currently
> implemented by typing the module expression in the usual way.
> > So extending it to a stronger form of module expression would require
> changing that, and introduce extra complexity.
> > Doable, but don't hold your breath...
> >
> > Jacques Garrigue
> >
>