From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 4AB777EF39 for ; Thu, 16 Jul 2015 18:01:01 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of philippe.veber@gmail.com) identity=pra; client-ip=209.85.217.177; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="philippe.veber@gmail.com"; x-sender="philippe.veber@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of philippe.veber@gmail.com designates 209.85.217.177 as permitted sender) identity=mailfrom; client-ip=209.85.217.177; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="philippe.veber@gmail.com"; x-sender="philippe.veber@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-lb0-f177.google.com) identity=helo; client-ip=209.85.217.177; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="philippe.veber@gmail.com"; x-sender="postmaster@mail-lb0-f177.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ByAgAf1KdVm7HZVdFaDoRCBoMerTySWQKBSAdMAQEBAQEBEgEBAQEBBgsLCSEuhCMBAQEDARIRHQEbHQEDAQsGAwIEBw0jBwICIgERAQUBHAYTIod2AQMKCJ1Ajz+BLD4xiz+BbIJ5iysKGScNV4RWAQEBAQEFAQEBAQEXAQUOiz6FBgeCaIFDBZRGjBiXNRIjgRUXgk2BAEA8MYJLAQEB X-IPAS-Result: A0ByAgAf1KdVm7HZVdFaDoRCBoMerTySWQKBSAdMAQEBAQEBEgEBAQEBBgsLCSEuhCMBAQEDARIRHQEbHQEDAQsGAwIEBw0jBwICIgERAQUBHAYTIod2AQMKCJ1Ajz+BLD4xiz+BbIJ5iysKGScNV4RWAQEBAQEFAQEBAQEXAQUOiz6FBgeCaIFDBZRGjBiXNRIjgRUXgk2BAEA8MYJLAQEB X-IronPort-AV: E=Sophos;i="5.15,488,1432591200"; d="scan'208";a="140254347" Received: from mail-lb0-f177.google.com ([209.85.217.177]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 16 Jul 2015 18:01:00 +0200 Received: by lbbpo10 with SMTP id po10so46299928lbb.3 for ; Thu, 16 Jul 2015 09:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uwdjalGaoD5JAMpLFOqHF/PcA6TgZya6Xg/L/AFX8b4=; b=oaZT68qzrD25LPzqcMOFPZZU8EFmqx2jiJwQk8rbg8qSVP0P2g2nDGTczyuvA+4dEh OEBPUwQYOBCknluKME+GniXLNAb+CmIpzQ6V8+nl4kKDbJXz2tVHemGxq7OK2++f5iZr ig0CzGhz95REQl45+RkWFjwNoRdQhtLP4gq88dwuAecBQUgILls4OVjQJSAucJ9eNs4X XBd0Jxt/TcYR0p1ZvhrfgFFALiU4dzToQZQco0ulzDl47MnZVF+IbYu4EovYilEiSSC5 1V1TY5UuSncMUUbC/+yPJmaffCkVNTG98XGBC9RHLuC76wy2rwAecsibVSDlmQisQlit sMxg== X-Received: by 10.152.21.103 with SMTP id u7mr9856893lae.49.1437062459870; Thu, 16 Jul 2015 09:00:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.127.208 with HTTP; Thu, 16 Jul 2015 09:00:40 -0700 (PDT) In-Reply-To: <10510894-97DB-4DA9-8334-F02C11E94504@math.nagoya-u.ac.jp> References: <10510894-97DB-4DA9-8334-F02C11E94504@math.nagoya-u.ac.jp> From: Philippe Veber Date: Thu, 16 Jul 2015 18:00:40 +0200 Message-ID: To: Jacques Garrigue Cc: OCaml Mailing List Content-Type: multipart/alternative; boundary=089e01493e7870d644051b002d6c X-Validation-by: philippe.veber@gmail.com Subject: Re: [Caml-list] Unwanted type constraint in mutually recursive parameterized class type definition. --089e01493e7870d644051b002d6c Content-Type: text/plain; charset=UTF-8 This workaround worked just fine, thanks a lot! ph. 2015-07-09 1:57 GMT+02:00 Jacques Garrigue : > On 2015/07/09 01:24, Philippe Veber wrote: > > > > Dear camlers, > > > > I obtain an unexpected answer from the toplevel when I enter the > following definition: > > > > OCaml version 4.03.0+dev7-2015-02-08 > > > > # class type ['a] c = > > object > > method m : d > > end > > and d = > > object > > inherit [int] c > > end > > ;; > > class type ['a] c = object constraint 'a = int method m : d end > > and d = object method m : d end > > > > What surprises me is the constraint 'a = int in the definition of c. Is > this is a bug or feature? > > > This is a feature (or at least, the intended behavior) > For classes, type constraints are inferred automatically, but in a > monomorphic way. > A standard workaround is to open the recursion by generalizing definitions: > > class type ['a,'d] c0 = object method m : 'd end > class type d = object inherit ['a,d] c0 end > class type ['a] c = ['a,d] c0 > > Jacques Garrigue --089e01493e7870d644051b002d6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This workaround worked just fine, thanks a lot!
ph.


2015-07-09 1:57 GMT+02:00 Jacques Garrigue <garrigue@math.n= agoya-u.ac.jp>:
On 2015/07/09 01:24, Philippe Veber wrote:
>
> Dear camlers,
>
>=C2=A0 =C2=A0I obtain an unexpected answer from the toplevel when I ent= er the following definition:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OCaml version 4.03.0+dev7-2015-02-08<= br> >
> # class type ['a] c =3D
>=C2=A0 =C2=A0object
>=C2=A0 =C2=A0 =C2=A0method m : d
>=C2=A0 =C2=A0end
> and d =3D
>=C2=A0 =C2=A0object
>=C2=A0 =C2=A0 =C2=A0inherit [int] c
>=C2=A0 =C2=A0end
> ;;
> class type ['a] c =3D object constraint 'a =3D int method m : = d end
> and d =3D object method m : d end
>
> What surprises me is the constraint 'a =3D int in the definition o= f c. Is this is a bug or feature?


This is a feature (or at least, the intended behavior)
For classes, type constraints are inferred automatically, but in a monomorp= hic way.
A standard workaround is to open the recursion by generalizing definitions:=

class type ['a,'d] c0 =3D object method m : 'd end
class type d =3D object inherit ['a,d] c0 end
class type ['a] c =3D ['a,d] c0

Jacques Garrigue

--089e01493e7870d644051b002d6c--