On Fri, 2006-10-13 at 15:01 +0200, Luc Maranget wrote:
> >     Bonjour,
> > 
> > Quoting Gerd Stolpmann <info@gerd-stolpmann.de>:
> > >Well, this is quite easy. The .mli file does not influence code
> > >generation. Code is generated when the .ml file is compiled, and it is
> > >only _checked_ afterwards if the types match the .mli file. This is
> > >simply the logic of the .mli.
> > 
> > Very well, but why ?
> > 
> >         Diego Olivier
> 
> By design, I guess.

Well here's a waffly explanation:

Interfaces act as constraints on what a module
exports. These constraints permit eliding some symbols.

They also permit abstracting types, or replacing types
with sub/supertypes (depending on variance) or specialisations.

The public,for example, could permitted to call a polymorphic
function only monomorphically:

let ident x = x 

is polymorphic but the mli file can say:

val ident : int -> int

This particular factor is almost essential working
with polymorphic variants.

I find this constraint mechanism is sometimes annoying BUT
I'd miss it if it were missing!

It's annoying because you tend to get unintuitive
type error diagnostics, and because one is often
forced to duplicate definitions from *.ml files
in *.mli files for no apparent reason (there is,
of course, a reason).


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net