From: Julian Assange <proff@iq.org>

> .mli files are highly redundant. Almost without exception all, or at
> the vast majority of .mli information can be generated from the
> underlying .ml implementation. We have programming languages to reduce
> redundancy, not increase it. Keeping mli and ml files in-sync is not
> only a waste of time, but error-prone and from my survey often not
> performed correctly, particularly where consistency is not enforced by
> the compiler (e.g comments describing functions and types). While
> exactly the same problem exists in a number of other
> separate-compilation language implementations, we, as camlers, should
> strive for something better.

I know the argument against .h files.
However I'm not sure it applies to .mli, which in my view have a role
rather different of C headers.

One first point is that they are optional. If you don't like the
burden of writing them (which is much simplified by the -i option of
the compiler), you can just avoid them. A tool like ocamlbrowser still
allows you to browse the contents of the .cmi file, thus giving access
to all type information. The only capacity you loose is export
control, but in many cases this doesn't really matter anyway.

So why do people write .mli files ? Just because it is nice to cleanly
separate interface and implementation. This goes completely against
some ideas in the OO community, particularly concerned by the close
relationship between specification and implementation, but thanks to a
more powerful type system, a larger part of the specification is
verifiable. A verifiable redundancy can be profitable, in fact all the
ML type system is about getting enough redundancy to your code to
detect errors.

Not to say that the current situation is perfect. The fact you have to
duplicate all type definitions is not so nice for instance. But for
people used to the .ml/.mli dichotomy, having both kind of information
united in a single file does not seem very attractive.

Practically what I usally do when I start a new project in Caml is
start without .mli files, until my project gets structured enough so
that I know what needs to be exported from each module. Then I
generate .mli's with the -i option of the compiler, trim definitions
to keep only the ones I need, and eventually add comments to
definitions (I'm often happy enough with labels only, but I know it's
not Good). From there on changes to the .mli are small enough, and
actually I want to know when the interface is changed, since this may
influence other modules.

Regards,

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>