From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <virgile.prevosto@m4x.org>
Delivered-To: caml-list@yquem.inria.fr
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39])
	by yquem.inria.fr (Postfix) with ESMTP id E5E22BBFA
	for <caml-list@yquem.inria.fr>; Wed, 22 Jun 2005 09:50:29 +0200 (CEST)
Received: from interferon.mpi-sb.mpg.de (ns.mpii.mpg.de [139.19.1.1])
	by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j5M7oToJ016698
	for <caml-list@yquem.inria.fr>; Wed, 22 Jun 2005 09:50:29 +0200
Received: from amavis by interferon.mpi-sb.mpg.de with scanned-ok (Exim 3.36 #1 (Debian))
	id 1Dl00D-0003br-00
	for <caml-list@yquem.inria.fr>; Wed, 22 Jun 2005 09:50:29 +0200
Received: from maildist ([139.19.90.238] helo=mpi-sb.mpg.de)
	by interferon.mpi-sb.mpg.de with esmtp (Exim 3.36 #1 (Debian))
	id 1Dl00A-0003b7-00
	for <caml-list@yquem.inria.fr>; Wed, 22 Jun 2005 09:50:26 +0200
Received: from mpiat2305 (Debian-exim@mpiat2305 [139.19.20.94])
	by mpi-sb.mpg.de (8.12.10+Sun/8.12.10) with ESMTP id j5M7oQVW013724
	for <caml-list@yquem.inria.fr>; Wed, 22 Jun 2005 09:50:26 +0200 (MEST)
Received: from loopback.mpi-sb.mpg.de
	([127.0.0.1] helo=mpiat2305 ident=prevosto)
	by mpiat2305 with esmtp (Exim 4.50)
	id 1Dl00A-0002ro-Ho
	for caml-list@yquem.inria.fr; Wed, 22 Jun 2005 09:50:26 +0200
Date: Wed, 22 Jun 2005 09:50:26 +0200
From: Virgile Prevosto <virgile.prevosto@m4x.org>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] type troubles with functors
Message-ID: <20050622095026.4dc5bcf0@mpiat2305>
In-Reply-To: <20050622064836.GA27983@pulp.anu.edu.au>
References: <8ecdad970506212153417f77b5@mail.gmail.com>
	<20050622064836.GA27983@pulp.anu.edu.au>
X-Mailer: Sylpheed-Claws 1.0.0 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: by AMaViS perl-11
X-Miltered: at concorde with ID 42B91845.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)!
X-Spam: no; 0.00; caml-list:01 functors:01 sig:01 val:01 sig:01 elt:01 val:01 elt:01 ord:01 struct:01 ord:01 explicitely:01 explicitely:01 2005,:98 tutto:98 
X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled 
	version=3.0.2
X-Spam-Level: 

Le 06/22/2005, =E0 04:48:36 PM, Pietro Abate a =E9crit:
> module type OrderedType =3D sig
>       type t
>       val compare : t -> t -> int
> end
>=20
>=20
> module type S =3D sig
>       type elt
>       type t
>       type set
>       val to_list : t -> elt list
>       val to_set : t -> set
> end
>=20
> module Make (Ord : OrderedType) : S =3D struct

I guess it might be useful to have as signature
'S with type elt =3D Ord.t', otherwise the elements of the sets would be
abstract as well.
Another solution for the module type would be to export explicitely the
set module -with another type constraint stating that it manipulate
elements of the same type as S itself:

module type S =3D sig
    type elt
    module EltSet: Set.S with type elt =3D elt
    type t
    val to_list : t -> elt list
    val to_set: t -> EltSet.t
end

This way, you'll have access directly to all the functions provided in
Set.S, while with the above signature, you must write them explicitely
in the signature S in order to use them (but this also allows you to
restrict the operations that are allowed on values of EltSet.t, which is
not the case when exposing the whole module).



--=20
E tutto per oggi, a la prossima volta
Virgile