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

[Malcolm Matalka <mmatalka@gmail.com>]

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

Ocamlc can produce mli files for you, but I generally write the mli first
anyways. I found the repetition annoying at first but I quickly found it to
be a none issue and has saved me a few times. Especially when type system
infers a different type than I thought,  the error is localized to the
module.
On Oct 30, 2012 10:18 AM, "Francois Berenger" <berenger@riken.jp> 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<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>
>>>
>>
>
> --
> 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: 5910 bytes --]