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 QAA18242 for caml-redistribution; Thu, 12 Aug 1999 16:51:13 +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 PAA15687 for <caml-list@pauillac.inria.fr>; Thu, 12 Aug 1999 15:17:37 +0200 (MET DST)
Received: from tcs.inf.tu-dresden.de (tcs.inf.tu-dresden.de [141.76.75.119])
	by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id PAA20220;
	Thu, 12 Aug 1999 15:17:30 +0200 (MET DST)
Received: from ithif20.inf.tu-dresden.de (ithif20 [141.76.75.120])
	by tcs.inf.tu-dresden.de (8.9.1a/8.9.1) with SMTP id PAA18113;
	Thu, 12 Aug 1999 15:16:56 +0200 (MET DST)
Received: by ithif20.inf.tu-dresden.de (SMI-8.6/SMI-SVR4)
	id PAA27233; Thu, 12 Aug 1999 15:17:43 +0200
Date: Thu, 12 Aug 1999 15:17:43 +0200
Message-Id: <199908121317.PAA27233@ithif20.inf.tu-dresden.de>
From: Hendrik Tews <tews@tcs.inf.tu-dresden.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Francois Pottier <Francois.Pottier@inria.fr>
Cc: caml-list@inria.fr
Subject: Re: Weird behavior with mutually recursive type definitions
In-Reply-To: <19990804155239.50895@pauillac.inria.fr>
References: <19990804155239.50895@pauillac.inria.fr>
X-Mailer: VM 6.34 under Emacs 19.34.1
Sender: weis


Francois Pottier writes:

   Date: Wed, 4 Aug 1999 15:52:39 +0200
   Subject: Weird behavior with mutually recursive type definitions
   
   [...]

     type 'a t = 'a dummy
      and specialized = int t
   
   O'Caml still accepts the code, but this time, it constrains 'a
   to be equal to int, as if the type constructor t could not be
   used polymorphically within its own declaration:
   
     type 'a t = 'a dummy constraint 'a = int
                          ^^^^^^^^^^^^^^^^^^^
     type specialized = int t
   
   Why is this? Can someone explain, or is it a typechecker bug?
   
A few month ago we run into the same problem. From a private
conversation with Jacques Garrigue I understood, that the above
behavior is actually a feature of the typechecker, because there
is no better solution known at the moment. :-(

We solved the problem by eliminating type abbreviations (by
replacing it with its expansion) until these constraints
vanished. (You can use option ocamlc -i on your code to see which
constraints are generated.) The elimination of the abbreviations
leads to ugly and unreadable code, but it works at least.

Hope this helps,

Hendrik