Re: automatic construction of mli files

[Gerard Huet <Gerard.Huet@inria.fr>]

At 16:03 02/08/00 +0400, Dmitri Lomov wrote:

>There are some things that I DO NOT like about OCaml .mli/.ml files, however.
>1) I have to duplicate type definitions  in .mli and in .ml files.
>   I think every ocamler knows how tedious is keeping consistency here.
>   Most of the time, you just change the definition in one of the files,
>   compile, get an error message, and (with curses ;)) copy definition to
another
>   file. I suppose complier can do this work for the user.
>   Maybe there is some hidden philosophy behind this... I will be happy
>   if someone explaint it to me

Just to add my 2 cents to this rambling discussion on interfaces. I used to
gripe myself about this duplication problem. But one day I realised that a
lot of this duplication could be avoided, because often the interfaces can
be designed as pieces of data structures definitions (DTDs), which consist
entirely of type declarations AND WHICH DO NOT NEED AN IMPLEMENTATION FILE
AT ALL, and pieces of method/exceptions descriptions, for which a .mli and
a .ml file share some redundancy, but where the programmer has the
opportunity to think carefully about what is visible from outside and at
what level of abstraction. 

Furthermore it is essential that we provide the possibility of designing
the interface BEFORE the code gets written, in order to do team work and
top-down design. For a large project, dummy implementations will typically
give a debugging environment to test your module, but here we want to check
the type consistency of these debugging dummies with respect to the master
.mli, as opposed to generate the .mli specs from them. 

I am currently working on a linguistic data base, where the data base
format is a BIG .mli describing the abstract syntax of my data base,
thinking about it as a DTD. This format is used as interface both to the
parser which reads in the data, and to the various processors, extractors,
and printers of the data base. This .mli file has no implementation
associated with it, and thus there is not any redundancy in terms of source
code. 

Of course, it is useful to have the facility to get the .mli from the .ml
for quick-and-dirty bottom-up programming. But as your program gets large,
and your modules become parametric functors, you really want to keep
separate your interface specs and your code, and the redundancy is slight.  

Gérard