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" 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 >> 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 >>> >> > > -- > 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 >