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.d...@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 _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
