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

[Hongbo Zhang <bobzhang1988@gmail.com>]

Hi all,
    It's correct that .mli is great for third-party library, but it's 
not helpful for in-house library and agile-development. Sometimes I have 
.mli thousands of lines long, it's not fun to sync it up....
    That's why I filed a feature request which uses access modifier 
'private' like F# http://caml.inria.fr/mantis/view.php?id=5764
    If you like the proposal, plz leave a comment to support it ;-)
On 10/30/12 5:18 AM, Francois Berenger wrote:
> On 10/30/2012 03:12 PM, Anton Lavrik wrote:
>> Hi Francois,
>>
>> I don't use .mli files that much. Granted, I'm a rather casual OCaml
>> user, but hey, at least you are not alone :)
>>
>> I'm surprised by some of the comments you've received. The fact that
>> some people tend to practice top-down coding more than others doesn't
>> really mean anything. Other people do it differently even regardless
>> of the language they use. For me, paper and pencil are far more useful
>> than .mli files up until the interfaces converge and stabilize.
>>
>> In general, .mli files are useful and even essential for libraries and
>> large projects. For instance, they allow to clearly (and cleanly)
>> define interfaces and help with separate compilation (i.e. to avoid
>> recompiling parts).
>>
>> The biggest inconvenience with .mli files as I see it is that I have
>> to repeat myself and make related but slightly different changes in
>> two places when I change a module implementation. I would very much
>> prefer to declare and document public interfaces next to the
>> implementation and have language tooling take care of separate
>> compilation and documentation generation.
>
> Thanks for pointing this out!
>
> The exact thing that would annoy me if I would adopt .mli files:
> repeating myself.
> In C, I used a tool call cproto to extract header files out of my .c
> implementation code. Then, I just snipped out some parts of the header
> I didn't want to make public, if I remember well.
> That was not perfect, but at least I did not have to maintain two
> files at the same time.
>
>> OCaml is kind of clumsy in this respect. For example, it does allow to
>> specify types for values and function parameters inline. The syntax
>> isn't the best, but the feature itself is very useful and I rely on it
>> all the time. But when I get to define a type signature for a function
>> e.g. in .mli file, I loose the ability to use parameter names and have
>> to specify them in the comments.
>>
>> Overall, I count .mli files as a fairly minor language usability
>> issue. Perhaps, it wouldn't be even very hard to fix, for example, by
>> allowing something like "[public] val value-name :  typexpr" in .ml
>> files so that .mli/.cmi files can be generated automatically with
>> desired public interfaces.
>
> I was thinking more about "export" as the keyword of choice,
> but the functionality would be exactly the same.
>
> Best regards,
> Francois.
>
>> Anton
>>
>>
>> On Mon, Oct 29, 2012 at 7:43 PM, Francois Berenger <berenger@riken.jp>
>> wrote:
>>> 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
>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>