Re: [Caml-list] Why should I use .mli files?

[Didier Cassirame <didier.cassirame@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3610 bytes --]

Indeed, I didn't know the "module type of" construct!

didier

2012/10/30 Romain Bardou <romain.bardou@inria.fr>

> Maybe you can just write "include module type of X" where X is the module
> which already has the .mli. Or you define the signature as a module type
> Sig in a separate file "x.ml" and write "include X.Sig".
>
> Cheers,
>
> --
> Romain Bardou
>
> Le 30/10/2012 16:52, Didier Cassirame a écrit :
>
>>
>> Thinking about it, there's at least one case where mli files are not so
>> useful: When you have several modules which must all comply with a
>> certain module type. In that case, all the mli files would be identical,
>> and a modification of the module type would necessitate to change all
>> the .mli.
>> What would be the best way to handle that situation?
>> I was thinking of making an inner module, coerce it to the desired type,
>> and open it afterwards, but the resulting module would still have a ref
>> to the inner module in its type.
>>
>> E.g.:
>>
>> in the file mymodule.ml <http://mymodule.ml>
>>
>>
>> -----------------------8<-----**--------------
>>
>> module Inner = (
>> struct
>>
>>    (* implementation *)
>>
>> end : Sig)
>>
>> open Inner
>>
>> -----------------------8<-----**--------------
>>
>> and the file sig.mli would be the required module type.
>>
>> didier
>>
>> 2012/10/30 Francois Berenger <berenger@riken.jp <mailto:berenger@riken.jp
>> >>
>>
>>
>>     Hello,
>>
>>     Here is my stupid question of the day:
>>     what's the use of those .mli files?
>>
>>     Is it just to separate interface from implementation
>>     so that the implementation of a module can be changed
>>     without clients of its interface to have to bother?
>>
>>     Does it make compilation of large software faster
>>     by allowing for more parallelization and maybe later on avoiding to
>>     recompile some parts?
>>
>>     Usually I program in a pure functional style, so my modules
>>     don't carry an internal state.
>>     I feel like "if someone want to re-use a function, so be it".
>>     If I really want to hide a function that I am afraid people
>>     may call in an incorrect manner, I declare it internally
>>     to some public function and use it correctly.
>>
>>     Also, maybe I only work on toy-size OCaml projects. So, I never
>>     bothrered to create any .mli file.
>>     I would like to know if I should bother about them.
>>
>>     Thanks a lot,
>>     Francois.
>>
>>     --
>>     Caml-list mailing list.  Subscription management and archives:
>>     https://sympa.inria.fr/sympa/_**_arc/caml-list<https://sympa.inria.fr/sympa/__arc/caml-list>
>>     <https://sympa.inria.fr/sympa/**arc/caml-list<https://sympa.inria.fr/sympa/arc/caml-list>
>> >
>>     Beginner's list: http://groups.yahoo.com/group/**__ocaml_beginners<http://groups.yahoo.com/group/__ocaml_beginners>
>>     <http://groups.yahoo.com/**group/ocaml_beginners<http://groups.yahoo.com/group/ocaml_beginners>
>> >
>>     Bug reports: http://caml.inria.fr/bin/caml-**__bugs<http://caml.inria.fr/bin/caml-__bugs>
>>     <http://caml.inria.fr/bin/**caml-bugs<http://caml.inria.fr/bin/caml-bugs>
>> >
>>
>>
>>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/**arc/caml-list<https://sympa.inria.fr/sympa/arc/caml-list>
> Beginner's list: http://groups.yahoo.com/group/**ocaml_beginners<http://groups.yahoo.com/group/ocaml_beginners>
> Bug reports: http://caml.inria.fr/bin/caml-**bugs<http://caml.inria.fr/bin/caml-bugs>
>

[-- Attachment #2: Type: text/html, Size: 4877 bytes --]