Re: [Caml-list] Re: "module type of" on sub-module of functor result

[Gabriel Scherer <gabriel.scherer@gmail.com>]

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
>