From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gclci-caml-list@m.gmane.org>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by yquem.inria.fr (Postfix) with ESMTP id 70EA3BC57
	for <caml-list@yquem.inria.fr>; Tue, 27 Apr 2010 16:45:05 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgYDAIeV1ktQW+UMmWdsb2JhbACQPowQFQEBAQEBCAsKBxEiwHmFDgSGJg
X-IronPort-AV: E=Sophos;i="4.52,280,1270418400"; 
   d="scan'208";a="57931009"
Received: from lo.gmane.org ([80.91.229.12])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 27 Apr 2010 16:45:05 +0200
Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <gclci-caml-list@m.gmane.org>)
	id 1O6m24-0006Dy-2c
	for caml-list@inria.fr; Tue, 27 Apr 2010 16:45:04 +0200
Received: from ks300734.kimsufi.com ([91.121.65.225])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <caml-list@inria.fr>; Tue, 27 Apr 2010 16:45:04 +0200
Received: from sylvain by ks300734.kimsufi.com with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <caml-list@inria.fr>; Tue, 27 Apr 2010 16:45:04 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: caml-list@inria.fr
connect(): No such file or directory
From: Sylvain Le Gall <sylvain@le-gall.net>
Subject: Re: Extending Set - strange behavior of abstract type
Date: Tue, 27 Apr 2010 14:40:00 +0000 (UTC)
Message-ID: <slrnhtdtq0.bpc.sylvain@gallu.homelinux.org>
References: <4BD6A0D9.7070900@wp.pl>
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: ks300734.kimsufi.com
User-Agent: slrn/pre1.0.0-11 (Linux)
X-Spam: no; 0.00; le-gall:01 struct:01 ord:01 orderedtype:01 struct:01 ord:01 orderedtype:01 char:01 char:01 wrote:01 abstract:01 compiles:01 functions:01 expression:02 module:03 

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