possible infinite loop in compiler

possible infinite loop in compiler

[Craig Falls]

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

Other row types such as [> `foo ] also cause the error.  The following
version returns a confusing (to me) error message:

module Foo : sig
   type 'a t = private 'a constraint 'a = [< `foo ]
 end = struct
   type 'a t = private 'a constraint 'a = [< `foo ]
 end

Signature mismatch:
 Modules do not match:
   sig type 'a t = private 'a constraint 'a = [< `foo ] end
 is not included in
   sig type 'a t = private 'a constraint 'a = [< `foo ] end
 Type declarations do not match:
   type 'a t = private 'a constraint 'a = [< `foo ]
 is not included in
   type 'a t constraint 'a = [< `foo ]

Re: [Caml-list] possible infinite loop in compiler

[Jon Harrop]

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.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

Re: [Caml-list] possible infinite loop in compiler

[Jacques Garrigue]

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