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

[Brian Hurt <brian.hurt@qlogic.com>]

On Fri, 6 Jun 2003, Chris Hecker wrote:

> 
> >Not sure what advantage this would gain.  Step #1 is about as difficult as
> >simply writting the .mli file directly.
> 
> Yeah, but not if things are changing a lot and you have big types and 
> whatnot.  Cutting and pasting or doing the ocaml -i thing is a bit of a 
> pain.  I could see it being a useful tool.  Basically anything that 
> eliminates repetition is a positive.

My basic opinion here: feel free to create such a tool.  Have fun.  *I* 
won't use it, but it's no skin off my nose either way.

If I'm heavily modifying a file *and* it's interface, I generally don't 
even bother with a .mli file.  That gets generated when the interface 
settles down.  If you're making big changes in the interface *and* have 
other files that depend upon the interface you're trying to keep up to 
date, then you're going to be having fun anyways.  Be thankfull the 
compiler detects all of those places you forgot to update.

Here's one problem I've hit several times.  In the .ml file, I do 
something like:

type t = foo * bar * bang

Then several functions that use type t.  The type inference will come up 
with types like:
    val add: foo * bar * bang -> foo -> bar -> bang -> foo * bar * bang
when what I wanted was:
    vall add: t -> foo -> bar -> bang -> t

How do you deal with this?

> 
> >I don't have a problem with .mli files being seperate from .ml files for
> >two reasons:
> >1) .mli is your external interface-
> >2) The compiler checks the signature of the .mli file
> 
> Don't forget "3) having a separate interface allows you to decouple 
> implementations which is important for large scale software".  Oh wait.
> 

Function calls are about 1-1.5 clock cycles the last time I measured them.  
I wouldn't have a problem if ocaml disabled all cross-module inlining.  
Inlining within a module is, IMHO, critical- but between modules I would
bet is sigifigantly less important.  People who have hard numbers feel
free to jump in.

Brian



-------------------
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