Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Automatic generation of mli files
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2003-06-06 (15:59)
From: Stefan Heimann <lists@s...>
Subject: Re: Re: [Caml-list] Automatic generation of mli files
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.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.


Stefan Heimann :: personal website.       :: CvsShell, a console based cvs client.

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: