Modules : type problem in functor

I have a problem with types in the following code (some easy module functional graph implementation). It seems that types are living their own lives.

I have type t = NotaEdge | Edge of int*v*v implemented in module Edge, this type in module Graph becomes type edge = E.t. Everything seems fine to me, except fact i can't pattern match on it, cause the constructor Edge is still undefined in module Graph.

Exactly in function suc when i try to match with Edge(l,n,m): #Error: Unbound constructor Edge

Hope someone can present it nicely, thx in advance :)

 module Vertex : Vertex with type label = int =

struct

  type t = NotaNode |  Node of int
  type label = int
  exception No of string

...

module Edge : Edge  with type label = int and type v = Vertex.t =
struct 

  type v = 开发者_运维问答Vertex.t
  type t = NotaEdge | Edge of int*v*v
  type label = int      

  exception No of string

...

module Graph (E : Edge) (V : Vertex) : Graph with type vertex = V.t and type edge = E.t =
struct 

  type vertex = V.t
  type edge = E.t
  type t = E.t list* V.t list

  let empty = ([],[])

 let rec suc (x:edge list) (v1:vertex) =
     match x with 
         y::ys -> (match y with
   (*Error-->*)       Edge(l,n,m) -> if n == v1 then m::(suc ys v1) else suc ys v1  
                     | _ -> [])
       |[] -> []

  let succ (t1:t) (v1:vertex) = 
    match t1 with
        (x,_) -> suc x v1

...

---

Things are a bit messy here; Error is never defined, and what I presume to be a few typos. It would be much more helpful if you gave code that compiled. Par it down, but syntactically correct. I can only make conjectures on the limited information and common pitfalls.

It would be very helpful to know the signatures to Vertex and Edge

If in the signature Edge the type t is defined the same as in the implementation of Edge that you give, then you can match the variant with E.Edge and E.NotaEdge. If the type t is abstract (the only information in the signature is type t), then you wont (and reasonably should not) be able to access the implementation or pattern match in that way. In this case the implementation is hidden behind the signature. This is usually fine (and intended) when dealing with functors since you can implement the module in any way that is necessary and convenient.