Version française
Home     About     Download     Resources     Contact us    
Browse thread
Extending Set - strange behavior of abstract type
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Sylvain Le Gall <sylvain@l...>
Subject: Re: Extending Set - strange behavior of abstract type
On 27-04-2010, Dawid Toton <d0@wp.pl> wrote:
> I tried to extend the standard Set module with new operations. I got 
> error messages about type incompatibilities (the Set.S.t as exposed by 
> my implementation and Set.S.t used by functions from the original Set). 
> I have reduced my code to the following small example:
>
> module Set = struct
>    module Make (Ord : Set.OrderedType) = struct
>      module Set = Set.Make(Ord)
>      include Set
>    end
> end
>
> module OrdChar = struct type t = char let compare = compare end
> module Raw1 = Set.Make (OrdChar)
> module Raw2 = Set.Make (struct type t = char let compare = compare end)
>
> let aaa (aa : Raw1.t) (bb : Raw1.Set.t) = (aa = bb)
> let aaa (aa : Raw2.t) (bb : Raw2.Set.t) = (aa = bb)
>
> Only the last line results in an error:
> Error: This expression has type Raw2.Set.t but is here used with type Raw2.t
>
> All the rest of the code compiles correctly. It means that types Raw1.t 
> and Raw1.Set.t can be unified.
>
> My question is: why these nearly identical statements results in 
> different behavior of the type t?
>
> I'd really prefer Raw1 and Raw2 to be identical.

You just have to propagate the type by hand:

module Set =
struct
  module Make (Ord : Set.OrderedType) =
    struct
      include Set.Make(Ord)
      module Set : Set.S with type t = t = Set.Make(Ord)
    end
end

The "type t = t" do the trick. The first t is bound inside Set and the other
comes from "include Set.Make(Ord)".

Regards
Sylvain Le Gall