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