From: Dmitri Lomov <dsl@tepkom.ru>
To: caml-list@inria.fr
Subject: Re: automatic construction of mli files
Date: Wed, 02 Aug 2000 16:03:36 +0400 [thread overview]
Message-ID: <39880E18.A0EB839@tepkom.ru> (raw)
In-Reply-To: <Pine.LNX.4.10.10008011518300.14334-100000@post.tepkom.ru>
I have lot of experience with Java, where there is no
explicit signatures present.
'public' in Java is like the EXPORT keyword that was proposed.
This makes any Java class a total mess of interface and
implementation. If you look at Java class you cannot figure out
the interface, because implementation pokes out everywhere.
Usually, if I need to understand some Java class, I have to
javadoc it, and then look at the resulting html. IMHO, that's awful.
Even C++ headers are better than this.
>From my point of view, OCaml .ml/.mli treatment is very good.
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
2) Just one little thing I could not figure how to do...
Suppose I have a module, called Eval, implementation of which
differs for bytecode and native-code generation.
What I wanted to do was:
- create an eval.mli in the root directory of my project
- create bytecode/eval.ml: bytecode implementation of eval.mli
- create i386/eval.ml: implementation of eval.mli for i386
- create alpha/eval.ml: implementation of eval.mli for Alpha &c
- compile versions of my program as follows:
ocamlc -o program bytecode/eval.cmo program.ml
ocamlopt -o program.opt i386/eval.cmx program.ml
You see here, that inside of program.ml I need not to know what versio I
compile (for bytecode or for i386 or for Alpha)
But this trick didn't do, because I was unable to compille eval.cmo and eval.cmx
When I did (in bytecode/)
ocamlc -c -I .. eval.ml
I got eval.cmi and eval.cmo (so ocamlc did not look eval.cmi in a root directory).
Can anybody suggest how to do this trick with OCaml?
Regards,
Dmitri
Anton Moscal wrote:
>
> On Tue, 25 Jul 2000, Jacques Garrigue wrote:
>
> > Not to say that the current situation is perfect. The fact you have to
> > duplicate all type definitions is not so nice for instance. But for
> > people used to the .ml/.mli dichotomy, having both kind of information
> > united in a single file does not seem very attractive.
>
> I think, SML `local' is a good alternative to interfaces in the many
> cases: `local' allows to hide definitions from the module interface
> without explicit signature specification.
>
> Regards,
> Anton Moscal
--
_________________________________________________________________
Dmitri S. Lomov
mailto:dsl@tepkom.ru ICQ#: 20524819 (Rusty)
+7 (812) 428-46-57 (b) +7 (812) 295-94-15 (h)
next prev parent reply other threads:[~2000-08-02 13:25 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 [this message]
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=39880E18.A0EB839@tepkom.ru \
--to=dsl@tepkom.ru \
--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