Version française
Home     About     Download     Resources     Contact us    
Browse thread
automatic construction of mli files
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Hendrik Tews <tews@t...>
Subject: Re: automatic construction of mli files
Julian Assange writes:
   From: Julian Assange <proff@iq.org>
   Date: 24 Jul 2000 15:34:22 +1000
   Subject: automatic construction of mli files
   
   .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 don't share your point of view. We have a big project (>100
files, approx 60000 lines of ocaml code). And the policy
regarding mli files is quite simple: If the mli file could be
generated from the source code, then, don't write one! The ocaml
compiler (together with ocamldep) will recognize its absence and
compile the ml file into both a cmo and a cmi file. 

If, on the other side, you really want to hide some type
information, then you provide an mli file and in this case it
cannot be generated from the ml file. In our project we have 26
mli files for 63 ml files. The rest is generated by the compiler.

Moreover I don't think redundancy is that bad. Redundancy helps
you to catch errors. I often write mli files even if they contain
only the information that would be infered by the comiler
automatically. But this redundant mli file helps me to catch
programming errors.

Bye,

Hendrik