From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id JAA17094 for caml-redistribution; Tue, 14 Sep 1999 09:16:02 +0200 (MET DST)
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA27407 for <caml-list@pauillac.inria.fr>; Mon, 13 Sep 1999 12:25:39 +0200 (MET DST)
Received: from p-voyageur.issy.cnet.fr (p-voyageur.issy.cnet.fr [139.100.0.39])
	by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id MAA13208
	for <caml-list@inria.fr>; Mon, 13 Sep 1999 12:25:39 +0200 (MET DST)
Received: from l-mhs1.lannion.cnet.fr ([161.104.1.59]) by p-voyageur.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id SC6D4QRV; Mon, 13 Sep 1999 12:26:54 +0200
Received: from lsun169.cnet (lsun169.lannion.cnet.fr [161.104.4.4]) by l-mhs1.lannion.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id S3HP5S82; Mon, 13 Sep 1999 12:25:30 +0200
Received: from lsun605.cnet (lsun605 [161.104.14.39])
	by lsun169.cnet (8.8.8+Sun/8.8.8) with ESMTP id MAA16670
	for <caml-list@inria.fr>; Mon, 13 Sep 1999 12:25:36 +0200 (MET DST)
Received: (from cregut@localhost)
	by lsun605.cnet (8.8.8+Sun/8.8.8) id MAA04038
	for caml-list@inria.fr; Mon, 13 Sep 1999 12:25:33 +0200 (MET DST)
X-Authentication-Warning: lsun605.cnet: cregut set sender to pierre.cregut@cnet.francetelecom.fr using -f
Date: Mon, 13 Sep 1999 12:25:32 +0200
From: "Pierre CREGUT - FT . BD/CNET/DTL/MSV" <pierre.cregut@cnet.francetelecom.fr>
To: caml-list@inria.fr
Subject: Parameterized signatures needed ?
Message-ID: <19990913122532.A4032@lsun605>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.5us
Sender: weis

Here is a small but complex puzzle with modules. I will use lowercase names for
modules and uppercase for signatures to simplify.

I have a process creating from a module a:A a module with two sub-modules
b:B and c:C containing both a same type t

  module F(a:A) : sig module b:B module c:C with type t = b.t end

>>From a and c I build other components. From b, I can also build other
things, they must be related later with the type t given by c.

So I want to build a functor d describing an a, building a c and using these,
b is also given back but not used inside d.
So A and C are fixed and well known but B is not and in fact there are
different kind of F giving different signature B.

  module d(X:sig
		module type B 
		module F(a:A) : sig 
		    module b:B 
		    module c:C with type t = b.t 
		  end
	      end) : 
    sig 
      type t
      module b : B with type t = t
      val ... : ... t ...
    end =
  struct
    module a = struct ... end
    module bc = F(a)
    type t = bc.b.t
    module b = bc.b and c = bc.c
  end

But I cannot speak of t because it is not a component of the abstract
signature B.

I could try 

   module b : B' where B' = sig type t include B end

but I will never relate a t in B and the specified t this way.

I could try in the specification of the functor argument

   module type B = sig type t end

but then B is really limited to what I gave.

So we lack something to parameterize such abstract signature : the "with type"
construct is too external.
May be we should dig out parameterized signatures :

  module type B(type t) = sig .... end

Its interface would be :

  module type B(type t)

and it would be used like this :

  module d(X:sig
		module type B (type t)
		module F(a:A) : sig module c:C module b: B(type t = c.t) end
	      end) : 
    sig 
      type t
      module b : B(t)
      val ... : ... t ...
    end

My questions are :
- is there another way to build d achieving the same result but with standard
  Objective Caml syntax ?
- are there been any work recently on parameterized signatures dealing with
  those problems ?

PS 1> a,b,c,d.. it looks like a stupid school example but i have real code 
behind it. b and c cannot be separated because the internal structure of the
abstract types provided by c depends on what you expect from b.

PS 2> parameterized signature existed in the original proposal for a module
system, but D. MacQueen showed that it was impossible to think of all the
possible sharing you wanted to express before hand. I am not considering
replacing sharing constraints with parameterized signatures but using both.

PS 3> parameterized signatures built this way are still rather abstract as
long as you do not try to use interface specifying their contents. 
I don't think there is any problem to type-check them and we are not threatened
by Lilibridge & Harper counter-examples.

-- 
Pierre Cregut - pierre.cregut@cnet.francetelecom.fr - +33 2 96 05 16 28
FT.CNET - DTL/MSV - 2 avenue Pierre Marzin - 22307 Lannion Cedex - France