From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA25981 for caml-red; Wed, 2 Aug 2000 15:25:25 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA24310 for ; Wed, 2 Aug 2000 14:03:39 +0200 (MET DST) Received: from post.tepkom.ru (post.tepkom.ru [195.9.10.12]) by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e72C3aX07379 for ; Wed, 2 Aug 2000 14:03:37 +0200 (MET DST) Received: (from root@localhost) by post.tepkom.ru (8.9.3/8.9.3) id QAA10664 for caml-list@inria.fr.ANTIVIRUS; Wed, 2 Aug 2000 16:03:31 +0400 Received: from tepkom.ru (young.tepkom.ru [195.19.226.44]) by post.tepkom.ru (8.9.3/8.9.3) with ESMTP id QAA10648 for ; Wed, 2 Aug 2000 16:03:29 +0400 Message-ID: <39880E18.A0EB839@tepkom.ru> Date: Wed, 02 Aug 2000 16:03:36 +0400 From: Dmitri Lomov Reply-To: dsl@tepkom.ru Organization: TEPKOM X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: ru,en MIME-Version: 1.0 To: caml-list@inria.fr Subject: Re: automatic construction of mli files References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: weis@pauillac.inria.fr 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)