From: Hendrik Tews <tews@tcs.inf.tu-dresden.de>
To: caml-list@inria.fr
Subject: Re: automatic construction of mli files
Date: Tue, 25 Jul 2000 13:48:05 +0200 (MET DST) [thread overview]
Message-ID: <200007251148.NAA19039@ithif20.inf.tu-dresden.de> (raw)
In-Reply-To: <wxhf9gytup.fsf@foo.iq.org>
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
next prev parent reply other threads:[~2000-07-25 22:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-07-24 5:34 Julian Assange
2000-07-24 20:48 ` Olivier Andrieu
2000-07-26 16:03 ` John Max Skaller
2000-07-24 22:02 ` Jean-Christophe Filliatre
2000-07-26 16:09 ` John Max Skaller
2000-07-24 22:09 ` John Prevost
2000-07-24 23:14 ` David Brown
2000-07-25 1:13 ` Jacques Garrigue
2000-08-01 11:22 ` Anton Moscal
2000-08-02 12:03 ` Dmitri Lomov
2000-08-02 14:13 ` Gerard Huet
2000-07-25 11:48 ` Hendrik Tews [this message]
2000-07-26 10:16 ` David Delahaye
2000-07-26 12:58 Damien Doligez
2000-07-27 17:46 ` Francois Rouaix
2000-07-27 19:04 Damien Doligez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200007251148.NAA19039@ithif20.inf.tu-dresden.de \
--to=tews@tcs.inf.tu-dresden.de \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox