From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <garrigue@math.nagoya-u.ac.jp>
X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr
X-Spam-Level: 
X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE 
	autolearn=disabled version=3.1.3
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39])
	by yquem.inria.fr (Postfix) with ESMTP id 8D606BC69
	for <caml-list@yquem.inria.fr>; Thu, 26 Apr 2007 02:17:01 +0200 (CEST)
Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1])
	by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l3Q0GxY8020397
	for <caml-list@yquem.inria.fr>; Thu, 26 Apr 2007 02:17:00 +0200
Received: from localhost (orion [130.54.16.5])
	by kurims.kurims.kyoto-u.ac.jp (8.13.7/8.13.7) with ESMTP id l3Q0GiCZ024249;
	Thu, 26 Apr 2007 09:16:44 +0900 (JST)
Date: Thu, 26 Apr 2007 09:16:37 +0900 (JST)
Message-Id: <20070426.091637.13771061.garrigue@math.nagoya-u.ac.jp>
To: jon@ffconsultancy.com
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] possible infinite loop in compiler
From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
In-Reply-To: <200704260049.15144.jon@ffconsultancy.com>
References: <180a05860704250624jc0fb974wd1c6ee7b64e93d23@mail.gmail.com>
	<200704260049.15144.jon@ffconsultancy.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 concorde with ID 462FEF7B.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)!
X-Spam: no; 0.00; compiler:01 stack:01 ocamlc:01 ocamlopt:01 foo:01 sig:01 foo:01 struct:01 wrote:01 caml-list:01 expressive:01 constraint:01 constraint:01 checking:02 garrigue:03 

From: Jon Harrop <jon@ffconsultancy.com>
> On Wednesday 25 April 2007 14:24, Craig Falls wrote:
> > The following code blows the stack in ocamlc and ocamlopt 3.09.3:
> >
> > module Foo : sig
> >    type 'a t = private 'a constraint 'a = [< `foo ]
> >  end = struct
> >    type 'a t = 'a constraint 'a = [< `foo ]
> >  end
> 
> This appears to have been fixed in 3.10.

Thanks for checking.

By the way, I wonder what is the intent of the above definition.
In a private definition, the row variable is not free, so using a
constraint does not help in any way. Writing
  type t = private [< `Foo]
would be just as expressive.

Jacques Garrigue