From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pjfrey@sympatico.ca>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by sympa.inria.fr (Postfix) with ESMTPS id 382347EEFC
	for <caml-list@sympa.inria.fr>; Mon, 16 Nov 2015 17:42:58 +0100 (CET)
IronPort-PHdr: 9a23:LaaJeBCt7SEaQvqlHdZmUyQJP3N1i/DPJgcQr6AfoPdwSP74pMbcNUDSrc9gkEXOFd2CrakU1qyL7OuwCSQp2tWojjMrSNR0TRgLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpQAbFhi3DwdpPOO9QteU1JTqkb3tsM2DKyxzxxODIppKZC2sqgvQssREyaBDEY0WjiXzn31TZu5NznlpL1/A1zz158O34YIxu38I46FppIZ8VvDxdqE8CLhZFygOMmYv5cStuwOQYxGI4y4EX3kbiBRSDhmNuAn4UI38owPhp+9l0TWbNsqwRrliCmfq1LtiVBK90HRPDDU+6myC0sE=
Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=pjfrey@sympatico.ca; spf=Pass smtp.mailfrom=pjfrey@sympatico.ca; spf=None smtp.helo=postmaster@torfep02.bell.net
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  pjfrey@sympatico.ca) identity=pra; client-ip=184.150.200.208;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="pjfrey@sympatico.ca";
  x-sender="pjfrey@sympatico.ca"; x-conformance=sidf_compatible
Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of
  pjfrey@sympatico.ca designates 184.150.200.208 as permitted
  sender) identity=mailfrom; client-ip=184.150.200.208;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="pjfrey@sympatico.ca";
  x-sender="pjfrey@sympatico.ca";
  x-conformance=sidf_compatible; x-record-type="v=spf1"
Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@torfep02.bell.net) identity=helo;
  client-ip=184.150.200.208;
  receiver=mail2-smtp-roc.national.inria.fr;
  envelope-from="pjfrey@sympatico.ca";
  x-sender="postmaster@torfep02.bell.net";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CfAADxBkpWnNDIlrhesF0GlGyGEAKBfxABAQEBAQEBARABAQEBAQYNCQkhLoItgggBAQQjFTMeCxoCBSECAg8CRhMIAQGIKqo3kBABLIEBhQyFRYUngk6BRAWOEYg3gVaUbpMoOIJSgXuGHwEBAQ
X-IPAS-Result: A0CfAADxBkpWnNDIlrhesF0GlGyGEAKBfxABAQEBAQEBARABAQEBAQYNCQkhLoItgggBAQQjFTMeCxoCBSECAg8CRhMIAQGIKqo3kBABLIEBhQyFRYUngk6BRAWOEYg3gVaUbpMoOIJSgXuGHwEBAQ
X-IronPort-AV: E=Sophos;i="5.20,303,1444687200"; 
   d="scan'208";a="187747131"
Received: from simcoe208srvr.owm.bell.net (HELO torfep02.bell.net) ([184.150.200.208])
  by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2015 17:42:57 +0100
Received: from bell.net torfep02 184.150.200.158 by torfep02.bell.net
          with ESMTP
          id <20151116164255.HSWM5833.torfep02.bell.net@torspm01.bell.net>
          for <caml-list@inria.fr>; Mon, 16 Nov 2015 11:42:55 -0500
Received: from [192.168.2.18] (really [70.55.216.69]) by torspm01.bell.net
          with ESMTP
          id <20151116164255.ICWJ24849.torspm01.bell.net@[192.168.2.18]>
          for <caml-list@inria.fr>; Mon, 16 Nov 2015 11:42:55 -0500
Message-ID: <564A078B.80309@sympatico.ca>
Date: Mon, 16 Nov 2015 11:42:51 -0500
From: peterfrey <pjfrey@sympatico.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: caml-list@inria.fr
References: <5645DC49.7050106@tu-berlin.de> <5645E255.5060900@freenet.de> <E51C5B015DBD1348A1D85763337FB6D9EA03E44B@Remus.metastack.local> <5645E9B4.9080007@cryptosense.com>
In-Reply-To: <5645E9B4.9080007@cryptosense.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Opwv-CommTouchExtSvcRefID: str=0001.0A020203.564A078F.01BA,ss=1,re=0.000,fgs=0
Subject: Re: [Caml-list] Cyclic type abbreviation

Interestingly, this definition is accepted:
>
> type tree = (int * 'a * 'a) option as 'a
>
> Here you are helping the type-checker because you give it a 
> "canonical" representation that it can use when unifying; it no longer 
> has to expand the type, potentially infinitely. I think the main point 
> is that the type is isorecursive, but I'm not really an expert on the 
> subject.
>
with this type-checking business I sometimes have the feel being Alice 
in Wonderland; its getting curiouser and curiouser ...

The type : type node = int * tree * tree  and tree = node option is, in 
fact, accepted if you use the -rectypes option.
I just checked it with utop -rectypes

I wonder if this is considered bad (dangerous) style; but there are 
several things that would not work for me without this option.

Peter Frey