From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 0CBE1BB9C for ; Thu, 19 Jan 2006 12:38:33 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k0JBcWj8016194 for ; Thu, 19 Jan 2006 12:38:32 +0100 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA04478 for ; Thu, 19 Jan 2006 12:38:31 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k0JBcTXt003937 for ; Thu, 19 Jan 2006 12:38:30 +0100 Received: from localhost (suiren [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.13.1/8.13.1) with ESMTP id k0JBcOgB009616; Thu, 19 Jan 2006 20:38:24 +0900 (JST) Date: Thu, 19 Jan 2006 20:38:20 +0900 (JST) Message-Id: <20060119.203820.30488493.garrigue@math.nagoya-u.ac.jp> To: a.baretta@barettadeit.com Cc: caml-list@inria.fr Subject: Re: [Caml-list] Constraints in module types From: Jacques Garrigue In-Reply-To: <43CF6FA7.8040604@barettadeit.com> References: <43CF6FA7.8040604@barettadeit.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 43CF7A38.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 43CF7A35.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 baretta:01 baretta:01 barettadeit:01 foo:01 foo:01 sig:01 syntax:01 sig:01 abstract:01 abstract:01 define:01 jacques:01 jacques:01 constraint:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 From: Alessandro Baretta > # type foo = [ `Foo of foo ];; > type foo = [ `Foo of foo ] > # module type BAR = sig type bar constraint bar = [ > foo ] end;; > The type constraints are not consistent. > Type bar is not compatible with type [> foo ] > > Is there a good reason for prohibiting the above declarations? Could I achieve a > similar effect with private row types? Not a "similar" effect, as the meaning of the above code is: define an abstract type bar, and check that this abstract type is unifiable with [> foo] (by definition impossible, so this might just be a syntax error...) On the other hand module type BAR = sig type bar = private [> foo] end means "require the type bar to be an instance of type [> foo]". I suppose this is what you intended? Jacques