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 6E0F37EE51 for ; Thu, 9 May 2013 04:27:13 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of milanst@gmail.com) identity=pra; client-ip=209.85.210.171; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="milanst@gmail.com"; x-sender="milanst@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of milanst@gmail.com designates 209.85.210.171 as permitted sender) identity=mailfrom; client-ip=209.85.210.171; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="milanst@gmail.com"; x-sender="milanst@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-ia0-f171.google.com) identity=helo; client-ip=209.85.210.171; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="milanst@gmail.com"; x-sender="postmaster@mail-ia0-f171.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0DACAJi1HRVdKrm2dsb2JhbABSgz6DPK0wjkh0CBYOAQEBAQEGCwsJFCiCHwEBBSMdARQHHQEDDAYFCw0CAiYCAiEBAREBBQEcBhMbh14BAw8MpC2Lbk+CfoRDChknDViHRwEFDIEaiyyCIzMHgkKBEwOTXYFrgWSBJoptgz0WKYRRIA X-IPAS-Result: Ai0DACAJi1HRVdKrm2dsb2JhbABSgz6DPK0wjkh0CBYOAQEBAQEGCwsJFCiCHwEBBSMdARQHHQEDDAYFCw0CAiYCAiEBAREBBQEcBhMbh14BAw8MpC2Lbk+CfoRDChknDViHRwEFDIEaiyyCIzMHgkKBEwOTXYFrgWSBJoptgz0WKYRRIA X-IronPort-AV: E=Sophos;i="4.87,638,1363129200"; d="scan'208";a="13656099" Received: from mail-ia0-f171.google.com ([209.85.210.171]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 09 May 2013 04:27:12 +0200 Received: by mail-ia0-f171.google.com with SMTP id r13so2719326iar.16 for ; Wed, 08 May 2013 19:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=YOpYZBRkIjH2/aq5SRAXKVfw0L4seJWqgRNfu04HO+w=; b=wveEiU66c2LZC88hryNFIYQr2Wz+qJvmbUmkyfUWKxObzxV2saMo/PDukrlsDyWmOw kgpYKAJbfS2s+UEerQbi8tGePcqpTCUPevJbARdbDyV28Pt9CCQcl3M5sHtryK06Kh4Q zOl3w7uFLnxA3+PFmBtSdpSi4vkMDtD7315N21Yp/TfZvixY9/a+/mTCPzgghrR+HHYV 4eh5HHgIkUzrroHwU8tTLhrBO/quYQhZ3cClNObbGDArLSopMvcxTf3uABqOAqULowdn P0+rRwf0BhJLm3hMb8gKJUkMEJkFY+YzHh8bJRaoc94kDfdguEGIPVPvmufoRco9MVin pKgw== X-Received: by 10.43.115.2 with SMTP id fc2mr3000509icc.27.1368066430834; Wed, 08 May 2013 19:27:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.12.34 with HTTP; Wed, 8 May 2013 19:26:30 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Milan_Stanojevi=C4=87?= Date: Wed, 8 May 2013 22:26:30 -0400 Message-ID: To: Markus Mottl Cc: Caml List Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] an issue with coercing private types Right, it seems (a : t1 :> t2) is actually a different operator that, as you said, should I always work. I was pointed to http://caml.inria.fr/pub/docs/manual-ocaml/expr.html#toc53 which explains this is some detail (and I should have searched harder it in the first place) Thanks everyone! On Wed, May 8, 2013 at 8:57 PM, Markus Mottl wrote: > On Wed, May 8, 2013 at 7:34 PM, Milan Stanojevi=C4=87 = wrote: >> but this compiles fine >> let to_int a =3D (a : 'a Foo.t :> int) > > This seems like the preferred solution and should always work, because > it enforces that "a" has a coercible type (rather than e.g. a mere > type variable) by the time type inference reaches the coercion > operator. Otherwise it may depend on the order in which the type of > sub-terms is inferred whether coercion will work. > >> and gives me the right type. >> >> What is wrong with the first version of [to_int]? Is this a bug in the >> compiler? I'm using ocaml 4.0.1 >> >> I also tried this with Foo.t that doesn't have phantom type variable >> and in that case both versions of [to_int] work. > > I'm actually surprised that removing the phantom type variable makes a > difference in that respect. I guess this just shows how unpredictable > the order of type inference can be, hence the need for proper type > annotations with coercions. > > Regards, > Markus > > -- > Markus Mottl http://www.ocaml.info markus.mottl@gmail.com