[Caml-list] Limitations of first-class modules

[Lauri Alanko <la@iki.fi>]

When first-class modules were announced for OCaml 3.12, I cheered them
as a sorely needed extension, and I have now begun to make heavy use
of them. I certainly prefer them over objects, even if I do find the
syntax of first-class modules a bit awkward. I would much prefer to
see a completely unified object-module system a la Scala, but I guess
such drastic changes are beyond the scope of OCaml's development
nowadays.

Anyway, I'm now beginning to stumble into the limitations of the
extension, and I'm a bit curious about their rationale.

In a type (module S), S must be a path to a named module type, and if
A and B are two different paths, (module A) and (module B) are
distinct even if A and B are transparent definitions for exactly the
same module types. This nominalism is quite surprising since one is
used to transparent definitions being just shorthands for signatures
that are compared structurally. In particular, this means that it is
no longer harmless to include a signature definition to compose a
convenience module from several submodules:

module A = struct 
  module type S = sig end
  type t = (module S)
  module M : S = struct end
  let v = (module M : S)
end

module B = struct
  include A
end

# module X : A.S = B.M;;
module X : A.S

# let x : A.t = B.v;;
Error: This expression has type (module B.S)
       but an expression was expected of type A.t = (module A.S)

Also, the limitations of package type constraints were also somewhat
surprising. The limitation about unpacking first-class modules in
functors was thankfully explained in the documentation, and it made
sense after a moment's reflection. No such rationale was included for
the rest of the design, so I'd be interested in hearing what's behind
it.


Lauri