Re: [Caml-list] Partially hiding modules in packages

[Alexey Rodriguez <mrchebas@gmail.com>]

Thanks to all who replied. I have solved my problem, but I still have
a question regarding clashing type definitions.

On Wed, Sep 9, 2009 at 9:40 PM, blue storm <bluestorm.dylc@gmail.com> wrote:
> The problem with your packages.tgz example is that you use "module
> type Foo = .." in the .mli. This gives the signature of a module type,
> that is, it refers to a _module type_ defined in the implementation
> file.
>
> What you want to do here is to give the signature of a _module_, not a
> module types, so here is the correct syntax :
>
>  module Foo : sig
>    type foo_t
>
>    val initial : foo_t
>    val show : foo_t -> string
>  end

Well spotted! I already encountered this before and at the time I
understood it, but I guess my brain forgot about it yesterday. Thanks
for checking the files, now it works. Whether the modules are
flattened in Foobar or not, I think it is orthogonal to the issue of
hiding (we both use the same solution). In our case I prefer to keep
the hierarchy as the packages tend to have many big modules.

I also checked the source code of mlpost, thanks for the tip
Jean-Christophe. This is probably the most promising solution.

Now I am trying to see how much reuse of "signatures" can be achieved.
Currently I defined the FOO and BAR signatures in sigs.ml. I include
them in the local mli files, for example:

foo.mli:
> include Sigs.FOO with type foo_t = int
>
> val unsafe_modify : foo_t -> foo_t

bar.mli:
> include Sigs.BAR with type foo_t = Foo.foo_t

And now the package signature is:
> module Foo : Sigs.FOO
> module Bar : Sigs.BAR with type foo_t = Foo.foo_t

This works great: the representation of Foo.foo_t is hidden and the
unsafe function is not visible. This requires adding the type foo_t to
the signature of Bar:

> module type BAR = sig
>  type bar_t
>  type foo_t
>  val initial : bar_t
>  val combine : bar_t -> foo_t -> foo_t
> end

So there is no free lunch here, I can reuse the signatures to avoid
repetition but I have to introduce extra type aliases to relate
signatures at include time. This could add some complexity for modules
sharing many types, and now I cannot include both FOO and BAR in the
same module due to clashing definitions of foo_t.

The only way that comes to my mind to avoid such clashes is to invent
new type alias names even though they refer to the same type. Is there
a nice methodology to avoid clashing type definitions when I want to
include two module (interfaces) that share types?

Cheers,

Alexey