From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA06642; Fri, 6 Jun 2003 17:59:29 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA06585 for ; Fri, 6 Jun 2003 17:59:28 +0200 (MET DST) Received: from carme.kasserver.com (h-62.141.48.121.keyweb.de [62.141.48.121] (may be forged)) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h56FxRH19603 for ; Fri, 6 Jun 2003 17:59:27 +0200 (MET DST) Received: from kunz.ratzer (dclient217-162-174-4.hispeed.ch [217.162.174.4]) by carme.kasserver.com (8.11.6/8.11.6) with ESMTP id h56FxRS12261 for ; Fri, 6 Jun 2003 17:59:27 +0200 Received: from stefan by kunz.ratzer with local (Exim 3.35 #1 (Debian)) id 19OJcq-0003Fg-00 for ; Fri, 06 Jun 2003 17:59:32 +0200 Date: Fri, 6 Jun 2003 17:59:32 +0200 From: Stefan Heimann To: caml-list@inria.fr Subject: Re: Re: [Caml-list] Automatic generation of mli files Message-ID: <20030606155932.GA12058@kunz.ratzer> Mail-Followup-To: caml-list@inria.fr References: <20030606095723.GA8096@kunz.ratzer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam: no; 0.00; caml-list:01 mli:01 ocamlc:01 foo:01 compiler:01 writting:01 lazy:02 06,:02 match:02 external:03 module:03 complex:03 wrote:03 interface:03 fire:96 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, Jun 06, 2003 at 10:33:25AM -0500, Brian Hurt wrote: > On Fri, 6 Jun 2003, Stefan Heimann wrote: > > > Hi, > > > > I searching for a way for generating the .mli file for a given source .ml > > file automatically. My basic idea is like that: > > > > (1) Specify in the .ml file which values and types should be exported > > and if a type should be exported abstract or not. This could be > > done with a special comment at the top of the file. > > > > (2) Filter the output of `ocamlc -i' to exclude the values and types > > that should not be exported and to make the types abstract if > > needed. > > Not sure what advantage this would gain. Step #1 is about as difficult as > simply writting the .mli file directly. Actually, a fairly fast way to > produce an mli file is to do ocamlc -i foo.ml > foo.mli and fire up your > local text editor and delete everything out of foo.mli you don't want > exported. I don't think that step #1 is as difficult as writing the .mli file by hand. If you have a complex type definition it's much easier to write `export my_type' than keeping the 2 definitions in the .ml and .mli file in sync. > I don't have a problem with .mli files being seperate from .ml files for > two reasons: It is not my problem that there is this separation between interface and implementation file. I think this is very good and helpful, especially when you want to see what functionality a module provides. I just want to make it easier to write the implementation file. Programmers are lazy and so writing an interface file should be as easy as possible. > 1) .mli is your external interface- changing that interface generally > means changing other files as well. In this case, you're generally > already chaging other files. > > 2) The compiler checks the signature of the .mli file against what is > produced by the .ml file, so if you do "accidentally" change an exported > function's interface, and forget to change the .mli to match, the compiler > will catch it. Maybe I should tell how I want to use the tool. I don't want to update the .mli file automatically everytime I change something in the .ml file. I want to use the compiler as I would do without the tool. The tool comes only into play when the compiler complains about a non-matching implementation for the interface. Then I have to decide if this is because I "accidentally" changed something in the implementation. If yes, I change to implementation. If no, I use to tool to update to .mli file instead of applying the changes by hand. Bye, Stefan -- Stefan Heimann http://www.stefanheimann.net :: personal website. http://cvsshell.sf.net :: CvsShell, a console based cvs client. ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners