From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=AWL,HTML_MESSAGE,SPF_NEUTRAL autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 3899DBBC4 for ; Thu, 16 Apr 2009 14:31:46 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIDAGvB5knRVdqyimdsb2JhbACCJjCSNFw/AQEBCgkMBw8FqXSQEwEEg32HZQ X-IronPort-AV: E=Sophos;i="4.40,198,1238968800"; d="scan'208";a="38579131" Received: from mail-bw0-f178.google.com ([209.85.218.178]) by mail4-smtp-sop.national.inria.fr with ESMTP; 16 Apr 2009 14:31:45 +0200 Received: by bwz26 with SMTP id 26so307956bwz.27 for ; Thu, 16 Apr 2009 05:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=AbQiBNwJ66caJpYt6r6xqeno/YU/Ur9O9Wfdec1s/7o=; b=wVjhR4DzFWP3JAac+lzT3DA5M/t5RrS/xPRcENlU2iPy6BWQuxavPloRSA93LRZYUc rTVVrLShkJ6/0tZR3RUwd+yOdhFVQI55Fcg2TBrIx2tlRZpacTr97L6HzR9ErVZ+yY6O 0WwTbfoW28dNBHk4x6S00whm2jxNf9nQ0x9a8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NVYs90X8PRy6UQJcZe3C/WzyhBZoYDBVx6+bnuGGBf/67w+o9Z2W1QQKiCNnOmhwvB dARS2gbXZtB7KwN2a2U2s3XGiEANI9hx0+rNkabFn8d4ykMb3oBG4hsYttCc7sm6M8Rd dvPHcI+1BuMnwciDpWUgOF/YfvoB594tpaWkE= MIME-Version: 1.0 Received: by 10.223.116.77 with SMTP id l13mr382344faq.106.1239885105391; Thu, 16 Apr 2009 05:31:45 -0700 (PDT) In-Reply-To: <20090416.212314.107686494.garrigue@math.nagoya-u.ac.jp> References: <721f7f5a0904150548o7351d50fm44aaf29b249b67f6@mail.gmail.com> <20090416.212314.107686494.garrigue@math.nagoya-u.ac.jp> Date: Thu, 16 Apr 2009 14:31:45 +0200 Message-ID: <721f7f5a0904160531h5b31fd0djac95fe0d534737fe@mail.gmail.com> Subject: Re: [Caml-list] Typing of polymorphic variants From: Philippe Veber To: Jacques Garrigue Cc: caml-list@yquem.inria.fr Content-Type: multipart/alternative; boundary=001636c5afb644e9bd0467ab3fe6 X-Spam: no; 0.00; variants:01 datatypes:01 recursion:01 datatype:01 abbreviation:01 abbreviation:01 datatype:01 recursive:01 datatypes:01 recursion:01 recursive:01 2009:98 2009:98 polymorphic:01 typing:01 --001636c5afb644e9bd0467ab3fe6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 2009/4/16 Jacques Garrigue > From: Philippe Veber > > I don't understand the following behaviour: > > > > Objective Caml version 3.11.0 > > > > # type t = [`A | `B of int u] and 'a u = 'a * t;; > > Error: In the definition of t, type int u should be 'a u > > # type t = A | B of int u and 'a u = 'a * t;; > > type t = A | B of int u > > and 'a u = 'a * t > > > > Anyone's got a simple explanation for this ? > > This is due to the difference between type abbreviations and > datatypes. In your first example, you are defining two types > abbreviations, and you are not allowed to instantiate a type you are > defining in mutual recursion. In the second example, you are defining a > datatype and a type abbreviation, and it is ok to instantiate the type > abbreviation inside the datatype definition. > > The technical reason for this difference is the restriction to regular > types in type abbreviations. It only applies when the definitions are > mutually recursive, and do not go through any datatype definition. Indeed, I noticed in other attempts that some definitions that would be accepted in the form type t = ... type u = ... were rejected in the form type t = ... and u = ... Now with your explanation it's clear why. Many thanks ! ph. > > > Jacques Garrigue > --001636c5afb644e9bd0467ab3fe6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2009/4/16 Jacques Garrigue <garrigue@math.nagoya-u= .ac.jp>
From: Philippe Veber <philippe.veber@googlemail.com>
> I don't understand the fol= lowing behaviour:
>
> =A0 =A0 =A0 =A0 Objective Caml version 3.11.0
>
> # type t =3D [`A | `B of int u] and 'a u =3D 'a * t;;
> Error: In the definition of t, type int u should be 'a u
> # type t =3D A | B of int u and 'a u =3D 'a * t;;
> type t =3D A | B of int u
> and 'a u =3D 'a * t
>
> Anyone's got a simple explanation for this ?

This is due to the difference between type abbreviations and datatypes. In your first example, you are defining two types
abbreviations, and you are not allowed to instantiate a type you are
defining in mutual recursion. In the second example, you are defining a
datatype and a type abbreviation, and it is ok to instantiate the type
abbreviation inside the datatype definition.

The technical reason for this difference is the restriction to regular
types in type abbreviations. It only applies when the definitions are
mutually recursive, and do not go through any datatype definition.

Indeed, I noticed in other attempts that some definitions that= would be accepted in the form type t =3D ... type u =3D ... were rejected = in the form type t =3D ... and u =3D ... Now with your explanation it's= clear why. Many thanks !

ph.
=A0


Jacques Garrigue

--001636c5afb644e9bd0467ab3fe6--