Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
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)



  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