[Caml-list] Exported Types

[Caml-list] Exported Types

[Nicolas Cannasse]

I got some problem using an "exported type" ( shared between modules ).
I know that I can avoid them by using polymorphic types but that'ld be nicer
without them.
I would also like of course to keep the files separated.

Here's a sample :

-- a.mli ---
type t (* exported *)

-- b.mli --
type t
val f : A.t -> t (* module B is using the type A.t but won't directly call
any A functions *)

-- b.ml --
type t = A.t (* quite stupid , but that's a sample ! *)
let f x = x

-- a.ml --
type t = int;;
ignore( B.f  (0:t) )
                 ---
(* This expression has type t = int but is here used with type A.t *)

I think this problem is quite standard, but I didn't find any clue on the
www
Any help will be welcomed

Nicolas Cannasse

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

Re: [Caml-list] Exported Types

[Jacques Garrigue]

From: "Nicolas Cannasse" <warplayer@free.fr>

> I got some problem using an "exported type" ( shared between modules ).
> I know that I can avoid them by using polymorphic types but that'ld be nicer
> without them.
> I would also like of course to keep the files separated.

The order of dependencies between modules is something strict: there
cannot be mutual recursion between two modules (at least, not
without doing some unsafe forward declarations using mutables).

Technically speaking, types do not depend on this order as long as you
provide .mli files (that is .mli and .ml order may be distinct), but
this is not a good idea to depend on it.
So I would rather suggest you forget about doing this.
What forces you so strongly to introduce such type level recursion?
Your example is too abstract to understand your goal.

In general, a reasonable approach would be to define A and B sharing
their types, and then define more abstract interfaces for them, to
call from outside.  With type abstraction, this should be possible.

But my experience of ML programming is that crafting interfaces is not
the point. The real point is using the right types.  Then you can
organize your code as you wish, anyway you cannot break it!

> -- a.mli ---
> type t (* exported *)
> 
> -- b.mli --
> type t
> val f : A.t -> t (* module B is using the type A.t but won't directly call
> any A functions *)
> 
> -- b.ml --
> type t = A.t (* quite stupid , but that's a sample ! *)
> let f x = x
> 
> -- a.ml --
> type t = int;;
> ignore( B.f  (0:t) )
>                  ---
> (* This expression has type t = int but is here used with type A.t *)

---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>
-------------------
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