Hiding private types

[David Rajchenbach-Teller <David.Teller@ens-lyon.org>]

     Dear list,

 I'm looking for a way to remove one or two annoyances of Batteries,
which are related to private magic leaking into the type system and into
the documentation.



We define a module [IO] with, among other things, a type [output]. In
fact, in order to avoid circular dependencies, [output] is actually
defined in a private module [InnerIO], which lets other modules such as
[ExtString] use [output] and still be used by [IO]. For instance,
[ExtString] defines a function [print : InnerIO.output -> string ->
unit].

At a later stage, we pack [IO], [InnerIO], [ExtString] and others into a
module [Extlib] and we later define a module [Batteries] containing

module IO          = Extlib.IO
module String = ExtString.String

etc.


Now, all of this works. Unfortunately, the types visible by the user,
either from the toplevel, from error messages or from -dannot, reveal
too much from the inner workings of Batteries.

For instance,  [InnerIO], as implied by the name, is private. The
existence of this module should not be visible by the user.
Unfortunately, on the toplevel, we have

# String.print;;
- : Extlib.InnerIO.output -> string -> unit = <fun>

Two abstractions have leaked out:
* the existence of [InnerIO]
* the existence of [Extlib]

I would rather have

# String.print;;
- : IO.output -> string -> unit = <fun>

or, at worst

# String.print;;
- : Batteries.IO.output -> string -> unit = <fun>


Does anyone have an idea of how we could/should do this?

Thanks,
 David

-- 
David Teller-Rajchenbach
 Security of Distributed Systems
  http://www.univ-orleans.fr/lifo/Members/David.Teller
   « Ce matin Un crétin A tué un chercheur. » (air connu)
   Latest News of French Research: System being liquidated. Researchers angry.