Version française
Home     About     Download     Resources     Contact us    
Browse thread
automatic construction of mli files
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Dmitri Lomov <dsl@t...>
Subject: Re: automatic construction of mli files
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)