From: David Brown <caml-list@davidb.org>
To: Julian Assange <proff@iq.org>
Cc: caml-list@inria.fr
Subject: Re: automatic construction of mli files
Date: Mon, 24 Jul 2000 16:14:02 -0700 [thread overview]
Message-ID: <20000724161401.B3623@opus.davidb.org> (raw)
In-Reply-To: <wxhf9gytup.fsf@foo.iq.org>; from proff@iq.org on Mon, Jul 24, 2000 at 03:34:22PM +1000
On Mon, Jul 24, 2000 at 03:34:22PM +1000, Julian Assange wrote:
> .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.
The redundancy is intentional, though. There are two differing
philosophies concerning the information in the mli file. One attitude,
taken by languages such as Eiffel, is that there should be no specification
file. The source contains markers to determine what is "public" and what
is "private". The compiler provides tools to generate specs for
documentation use.
The other attitude, taken by Ada, and sort of, but not really, by C, is
that the spec file is a document of the interface to the module. The
implementation is independent from the spec. The developer should feel
free to implement the spec as needed, as long as it complies with that
interface.
Both methods have advantages and disadvantages.
- The single file approach is easier for the programmer to create,
especially when doing rapid prototyping.
- The single file approach makes it less obvious if a given change is going
to change the interface. A separate spec can be checked against to
verify that the developer didn't change the interface.
- The separate spec is usually difficult for those first learning the
language. Ocaml helps here by not requiring the spec to be written, and
even generating it for you.
There are very strong arguments by big names for both sides. Ocaml, like
it does in many areas, leaves the choice up to the developer.
If you wish to have a single file, don't write a .mli file at all. Modules
will export all symbols by default if there is no spec. If you want to
make a spec when you are done, compile the modules with -i, and redirect
the output to the spec file. Feel free to comment it, and delete the
symbols you didn't really want to export.
For those who wish to use a more "structured" approach to development, the
spec can be written first. Then the compiler will verify that the code
written corresponds with the spec.
The challenge, then is to figure out which methodology I prefer :-).
Dave Brown
next prev parent reply other threads:[~2000-07-25 21:55 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 [this message]
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
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=20000724161401.B3623@opus.davidb.org \
--to=caml-list@davidb.org \
--cc=caml-list@inria.fr \
--cc=proff@iq.org \
/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