From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p0JCXgB3021284
	for <caml-list@sympa-roc.inria.fr>; Wed, 19 Jan 2011 13:33:42 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjkBAI9oNk2A1gkBe2dsb2JhbACWKo4vAQEWIgUfwFaFUASFLA
X-IronPort-AV: E=Sophos;i="4.60,344,1291590000"; 
   d="scan'208";a="87414742"
Received: from courier.cs.helsinki.fi (HELO mail.cs.helsinki.fi) ([128.214.9.1])
  by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jan 2011 13:33:36 +0100
Received: from melkinpaasi.cs.helsinki.fi (melkinpaasi.cs.helsinki.fi [128.214.9.14])
  (AUTH: PLAIN cs-relay, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
  by mail.cs.helsinki.fi with esmtp; Wed, 19 Jan 2011 14:33:35 +0200
  id 00093EB8.4D36DA1F.0000416B
Received: by melkinpaasi.cs.helsinki.fi (Postfix, from userid 37211)
	id BC9A1821F1; Wed, 19 Jan 2011 14:33:35 +0200 (EET)
Date: Wed, 19 Jan 2011 14:33:35 +0200
From: Lauri Alanko <la@iki.fi>
To: caml-list@inria.fr
Message-ID: <20110119123335.GL323@melkinpaasi.cs.helsinki.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: [Caml-list] Limitations of first-class modules

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