I'm surprised no one has mentioned that it can speed up compilation by not having to recompile cmx files unnecessarily. On May 31, 2013 8:42 AM, "Yaron Minsky" wrote: > I concur. I think this is largely the accepted wisdom among experienced > OCaml developers. > > y > On May 31, 2013 11:21 AM, "Hongbo Zhang" 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 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 >> Beginner's list: http://groups.yahoo.com/group/**ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-**bugs >> >