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 PAA03470 for caml-redistribution; Mon, 20 Sep 1999 15:17:21 +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 PAA26054 for ; Fri, 17 Sep 1999 15:01:10 +0200 (MET DST) Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33]) by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id PAA06793; Fri, 17 Sep 1999 15:01:09 +0200 (MET DST) Received: from l-mhs1.lannion.cnet.fr ([161.104.1.59]) by p-biset.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id SC610RZJ; Fri, 17 Sep 1999 15:02:12 +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 S3HP5X0P; Fri, 17 Sep 1999 15:01:13 +0200 Received: from lsun605.cnet (lsun605 [161.104.14.39]) by lsun169.cnet (8.8.8+Sun/8.8.8) with ESMTP id PAA15573; Fri, 17 Sep 1999 15:01:07 +0200 (MET DST) Received: (from cregut@localhost) by lsun605.cnet (8.8.8+Sun/8.8.8) id PAA04929; Fri, 17 Sep 1999 15:01:04 +0200 (MET DST) X-Authentication-Warning: lsun605.cnet: cregut set sender to pierre.cregut@cnet.francetelecom.fr using -f Date: Fri, 17 Sep 1999 15:01:04 +0200 From: "Pierre CREGUT - FT . BD/CNET/DTL/MSV" To: Xavier Leroy Cc: Francois Pottier , "Pierre CREGUT - FT . BD/CNET/DTL/MSV" , caml-list@inria.fr Subject: Re: Parameterized signatures needed ? Message-ID: <19990917150104.A4910@lsun605> References: <19990913122532.A4032@lsun605> <19990914114600.57679@pauillac.inria.fr> <19990916185939.24663@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: <19990916185939.24663@pauillac.inria.fr>; from Xavier Leroy on Thu, Sep 16, 1999 at 06:59:39PM +0200 Sender: weis > This looks less natural to me. A very limited form of "row > polymorphism" can already be expressed with module type parameters and > sub-structures, as in: > > module d(X:sig > module type X > module F(a:A) : sig > module b: sig type t module M: X end > module c:C with type t = b.t > end > end) : ... > > but it's very limited and not really practical. > Only because you cannot express sharing type constraints on M because X is abstract. As it is written, you have a module b with a type t and a contents that does not use it. You can also write [module b : sig type t include X end] but this does not solve the problem and it express more than you want. All I would like to say is if there is a t used in X then it has to be this C.t but I do not require t to exist. But the [with type] construct adds that t must exist and must be immediately checkable. So in fact there are two solutions : - allow [X with type t = C.t] even if X is abstract and may not have a t component : it means that if X is realized by a signature with a type t then we add the constraint t = C.t - X(t) (the solution proposed in my first post) : then the type does not need to be named t in X(t) as we can say module type X(t) = sig type u = t end The first solution is more limited but adds no syntax. It just requires a special treatment of defered constraints for abstract signature when X is given an actual value. I am not sure it is strictly related with subtyping. It deals only with the stamp calculus, not with the visibility of components. -- 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