About that missing type constructors problem. Seems doable:

module A = struct
  module T = struct
    type t1 = ...
    type t2 = ...
  end
  include T

  let foo _ = ...
  let bar : t2 -> t1  = ...
end

module B = struct

  include A.T
  let foo, bar = A.( foo, bar )

end

Obviously, not for already existing code.

În sâm., 16 iul. 2016 la 10:41, Petter A. Urkedal <paurkedal@gmail.com> a scris:
On 15 July 2016 at 18:13, Hendrik Boom <hendrik@topoi.pooq.com> wrote:
> And that's a real problem -- that fact that openning a module can fill
> the namespace with lots of stray identifiers, which the user does not
> control.

Apart from the selective opens discussed, it would be good to tell
apart which modules are meant to be open and which are intrusive
without looking through them.  Most importantly the writer of the
library should be clear about it from the start when designing a
module, then the names will be consistent with the choice, and users
should be able to decide without evaluating the whole interface.

A warning when opening an invasive module in a global scope could
help, as well.  One could maybe decide a module to be invasive from a
few heuristics with fall-back to a declaration:

- A module interface defining a single-letter identifier, most
importantly a type "t" or a signature "S", is invasive.
- A module interface overriding any operator (or identifier?) defined
in Pervasives is invasive.
- A module interface declaring itself `[@@@ocaml.invasive]` is invasive.

Conversely the user may silence the warning with `open M [@@ocaml.invasive]`.

--
Caml-list mailing list.  Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs