Re: [Caml-list] Re: automatic extaction of the .mli (and a little more) from the .ml

[Yaron Minsky <yminsky@janestreet.com>]

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

I concur.  I think this is largely the accepted wisdom among experienced
OCaml developers.

y
On May 31, 2013 11:21 AM, "Hongbo Zhang" <bobzhang1988@gmail.com> wrote:

> On 5/31/13 1:31 AM, Malcolm Matalka wrote:
>
>> I know of no such tool, but in counter to your premise: I used to think
>> maintaining a .ml and .mli was foolish, however I no longer do.  .mli is
>> effectively documentation for me.  It contains a lot of comments and is
>> generally written to reflect how the API should be used rather than the
>> order in which I must express functions to get ta .ml to compile.  On
>> top of that, ocamlc will fail to compile if your .ml and .mli don't
>> match, so it's a valuable check that what I think my module does is also
>> what the compiler does.  I also tend to write the .mli first, then write
>> the .ml.  I find it to be a great way to develop.
>>
>> In short, I think it's a good thing to maintain these things by hand.
>> But as for your original question I'm completely useless, sorry.
>>
>>  I had the same experience with you, after writing some large software in
> ML, I found it better to maintain mli by hand.
>
>> /M
>>
>> Francois Berenger <berenger@riken.jp> writes:
>>
>>  Hello,
>>>
>>> Is there some recommended tool/script to generate a .mli
>>> from the corresponding .ml?
>>>
>>> I want a little more than ocamlc -i:
>>>
>>> - I think there should be tags in the .ml file as comments
>>>    that say "export this" to the .mli.
>>>    By default, things are not exported.
>>> - maybe it should have an option to say to replicate
>>>    the ocamldoc comments in the .mli.
>>> - it could be nice if the order in which things are exported
>>>    to the .mli can be specified, maybe as an argument of the tag.
>>>    So that the .mli can be more readable (only backward references
>>>    to concepts, etc.)
>>>
>>> If there is a need to create a tool, let's call it "nomli". :)
>>>
>>> Regards,
>>> F.
>>>
>>> PS: I'm not going to maintain both a .mli and a .ml.
>>>      I feel it is a dumb and error-prone job and that
>>>      itches me.
>>>
>>
>>
>
> --
> 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: 3371 bytes --]