Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] type issues with modules
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@k...>
Subject: Re: [Caml-list] type issues with modules
From: Chris GauthierDickey <chrisg@cs.uoregon.edu>

> I have a weird issue, but I'm not sure if it's related to the type
> system or what's really going on.  I've boiled the problem down to the
> simple case below. I have 4 files, two that are interfaces for the modules.
> 
> file: mod1.mli
> type t1 = T1
> val v: t1
> 
> file mod1.ml
> type t1 = T1
> let v = Mod2.f2 ()
> 
> file mod2.mli
> val f2: unit -> Mod1.t1
> 
> file mod2.ml
> let f2 ()  = Mod1.T1
> 
> 
> I compile the files as such:
> 
> ocamlc -g mod1.mli
> ocamlc -g mod2.mli
> ocamlc -g mod1.ml
> 
> at which point I get the error:
> The implementation mod1.ml does not match the interface mod1.cmi:
> Values do not match: val v : Mod1.t1 is not included in val v: t1

Explanation:
As specified in the reference manual, the combination of .ml and .mli
is expected to mean:
  module type Sig_mod1 = sig <mod1.mli> end
  module Struct_mod1 = struct <mod1.ml> end
  module Mod1 : Sig_mod1 = Struct_mod1
This means that during the typing of the contents of mod1.ml, the
compiler does not know yet that it is defining Mod1 (no recursion).
As a result, the t1 in mod1.ml and the Mod1.t1 in mod2.mli are not
known to represent the same type. Hence the error.

Moreover, the possibility of creating mutual dependencies between
modules by compiling a module against a .mli of another module
depending on the first one is not intentional, and should probably not
be relied upon.

> P.S. I know I can move t1 into another module, but for software
> engineering reasons, I don't want to do that.

I'm wondering what you mean by software engineering reasons.
That you want to keep types and values in the same module?
Unfortunately, this does not work well with the absence of recursion
between modules. Putting all types in a third module is indeed the
simplest solution.

Jacques Garrigue

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