Browse thread
automatic construction of mli files
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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