[Caml-list] Are record types generative?

[Oleg <oleg@okmij.org>]

I have recently received a rather odd type error:

       Type declarations do not match:
         type t = D.Product.t = { pid : int; name : string; price : int; }
       is not included in
         type t = RProduct.t = { pid : int; name : string; price : int; }

Apparently, two structurally identical record types are not regarded
equal (OCaml 4.04.0). The original code is a bit complicated, so
let me illustrate the problem on a simple example:

module type m1 = sig
  type t = int
  val v : t
end

module M1 : m1 = struct
  type t = int
  let v = 1
end

module F1(S:m1) = struct
  let res = S.v = M1.v
end

let _ = let module M = F1(M1) in M.res;;

This code is accepted with no problems and gives the expected result
(1 is indeed equal to 1). Module M1 was checked to satisfy the
signature m1; therefore, S.v and M1.v should have the type int and be
the same.

Let's change the example slightly

module type m2 = sig
  type t = {l:int}
  val v : t
end

module M2 : m2 = struct
  type t = {l:int}
  let v = {l=1}
end

module F2(S:m2) = struct
  let res = S.v = M2.v
end

  Characters 43-47:
    let res = S.v = M2.v
                    ^^^^
Error: This expression has type M2.t but an expression was expected of type
         S.t

Although both M2 and S are two instances of m2, and hence both
S.v and M2.v  should have the record type t = {l:int}, they are not
regarded equal.

The problem is easy to fix:

module F3(S:m2 with type t = M2.t) = struct
  let res = S.v = M2.v
end
;;

  module F3 :
  functor (S : sig type t = M2.t = { l : int; } val v : t end) ->
    sig val res : bool end

let _ = let module M = F3(M2) in M.res;;

but even in this simple case the fix is ugly (and becomes uglier in
the real code). Maybe there is a way to avoid adding too many sharing
constraints?

BTW, the new manual has a section about common polymorphism
pitfalls. Modules also have a fair share of dark corners (along with
the objects). Perhaps there could be a section in the manual about
not so obvious aspects of modules (in the first approximation,
just collecting questions and answers like the present one).