Re: Re: [Caml-list] Automatic generation of mli files

[Stefan Heimann <lists@stefanheimann.net>]

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