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

[Romain Bardou <romain.bardou@inria.fr>]

Usually the code you have to duplicate is type definitions which are not 
private. If you don't want to copy-paste them, you can put them in a 
separate file, which you open in the .mli and the .ml.

I often wished for this "private" or "public" keywords myself though. 
But it's not clear what would be the best implementation. For instance:

type t = int
public let f x = x + 1

What should be the type of f in the inferred interface? "int -> int" or 
"t -> int" or "t -> t" or "int -> t"? What about type t, should it be 
"type t = private int" in the interface? Or "type t"?

Cheers,

-- 
Romain Bardou

Le 30/10/2012 12:41, Hongbo Zhang a écrit :
> 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
>>
>>
>
>