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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 40F7C7EE34 for ; Sun, 27 Mar 2016 20:52:57 +0200 (CEST) IronPort-PHdr: 9a23:l5TP5xO5mlhG2JV1M9ol6mtUPXoX/o7sNwtQ0KIMzox0KPj8rarrMEGX3/hxlliBBdydsKIUzbCN+Pm7ASQp2tWojjMrSNR0TRgLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpQAbFhi3DwdpPOO9QteU1JTnkbrpsMSIO01hv3mUX/BbFF2OtwLft80b08NJC50a7V/3mEZOYPlc3mhyJFiezF7W78a0+4N/oWwL46pyv50IbaKvW6k/BYNYDSgrezQx6crDsQHcF1bJ4HYABDY4iB1NViff4R79RIa5lyL+u+F90WHOMsj/Sb0/WT2K4KJiSRuugyACYW1quFrLg9B92foI6CmqoAZyltbZ Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=gmalecha@gmail.com; spf=Pass smtp.mailfrom=gmalecha@gmail.com; spf=None smtp.helo=postmaster@mail-ob0-f175.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gmalecha@gmail.com) identity=pra; client-ip=209.85.214.175; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gmalecha@gmail.com"; x-sender="gmalecha@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gmalecha@gmail.com designates 209.85.214.175 as permitted sender) identity=mailfrom; client-ip=209.85.214.175; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gmalecha@gmail.com"; x-sender="gmalecha@gmail.com"; 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@mail-ob0-f175.google.com) identity=helo; client-ip=209.85.214.175; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gmalecha@gmail.com"; x-sender="postmaster@mail-ob0-f175.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AHAQCUK/hWkq/WVdFchH4GqEiHKYxyhg0CgRYHOxEBAQEBAQEBARABAQEBBwsLCSEvgi2CFQEBAwESER0BGx0BAwELBgUEBzcCAiIBEQEFARwGEyKHbwEDCgiiLIExPjGLNoFqgleGKAoZJw1RhB0BAQEBBgEBAQEBARQBBQoFhRd4hESHPIJWBY4whFaEW44GjwuNTREegQ82giIegXEcMIhWAQEB X-IPAS-Result: A0AHAQCUK/hWkq/WVdFchH4GqEiHKYxyhg0CgRYHOxEBAQEBAQEBARABAQEBBwsLCSEvgi2CFQEBAwESER0BGx0BAwELBgUEBzcCAiIBEQEFARwGEyKHbwEDCgiiLIExPjGLNoFqgleGKAoZJw1RhB0BAQEBBgEBAQEBARQBBQoFhRd4hESHPIJWBY4whFaEW44GjwuNTREegQ82giIegXEcMIhWAQEB X-IronPort-AV: E=Sophos;i="5.24,402,1454972400"; d="scan'208,217";a="210551737" Received: from mail-ob0-f175.google.com ([209.85.214.175]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 27 Mar 2016 20:52:56 +0200 Received: by mail-ob0-f175.google.com with SMTP id m7so86436674obh.3 for ; Sun, 27 Mar 2016 11:52:56 -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; bh=EDl3DRwydOKZXNp1u+jrc+6c0/ItpLAWBhCWkOQWzYM=; b=taXLOpCcUA7ui6iLvAO570MLVOwdNIegxCgEhh6wD/M+BYkghPW0Mz7FpZCZxiQu3+ tHonUGGggl5CDRpE/4YJ+EMlhZO8XvUajofFyod6duzgbXyuNn67JB0jmHHjpJdKe60P MYU0sMb22z9jcsdoh2/ntzMGH5Ivr5znxpRjNeC2lA8QT2234j5Ak1I28i99JGRQn6tw aEJ6YaOBqEEfZ/47NRI2wOps+Q8kS1FEVZJd+Wdv9UeqRQo8BNIFP6sQy9gPuh/WKqUI mBm0wD0LUG1MqbLbnK3J4iwb8TTUD3K7xrrR6vCg+PtLMPubC/nkj6SOdD3A2B7Al64v Lo0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EDl3DRwydOKZXNp1u+jrc+6c0/ItpLAWBhCWkOQWzYM=; b=DfctSDiRZC9L5/67zn/AI7nBIJfc109gzUQV53MbaFBsAEVY5avz3GvJ3HVtdrxGT1 3jXNU38VsW4gVol+RVsrm6bldm1oAduPo8WtLD9zIMyAJ9BhZl4Svael/VWwLHG5YPWP liKriuspZfXPBm8KE/QC03kxH6IW5kvquYQkMYmuMrA1T4GnMN//RJ8w9eaKRrPcH3HA hPdQXAhrakPlo2VxnMBGe40VmDLoVheNU8wd8UcQUbTr1EYDJHBLJ0aRIBkI6X5wQQZA 7iHJRYVzDpkrOIOO4aSdPJBBA9/AfJbTP5xIDprdWcS/hi3FlsN0Ye72IrUSKOFl18Wu TqJw== X-Gm-Message-State: AD7BkJLyclTOFME2TJJXuceq4lJgo/n0RuPCYeRZR96AJqw4sYEQzeQaC9y1EfUUmtw9ZXFoxsUqz5KnPR+oXQ== X-Received: by 10.182.24.8 with SMTP id q8mr10315022obf.67.1459104775171; Sun, 27 Mar 2016 11:52:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.19.43 with HTTP; Sun, 27 Mar 2016 11:52:15 -0700 (PDT) In-Reply-To: <86d1qgqu45.fsf@lpw25.net> References: <86d1qgqu45.fsf@lpw25.net> From: Gregory Malecha Date: Sun, 27 Mar 2016 11:52:15 -0700 Message-ID: To: Leo White Cc: caml users Content-Type: multipart/alternative; boundary=001a11c24b38d07ce1052f0c4da0 Subject: Re: [Caml-list] "Type constructor b would escape its scope" --001a11c24b38d07ce1052f0c4da0 Content-Type: text/plain; charset=UTF-8 Thanks, Leo -- This is exactly what I needed to know. I thought that the (type a) annotation was forcing the function to be polymorphic. For future reference, is there any way to write the annotation (that forces the function to be polymorphic) without having to write explicit 'fun's? Thanks. On Sun, Mar 27, 2016 at 12:04 AM, Leo White wrote: > This is a guess since you didn't include the definition of > stream_declarations, but I suspect that: > > > (* I have the following function, which seems to type check *) > > let stream_declarations (type a) > > : (internal_result,a) result_stream = ... > > is not polymorphic. The `(type a)` annotation ensures that `a` is > abstract in the body of `stream_declarations` but does not enforce > that the result is polymorphic -- in particular I suspect that you > are running up against the value restriction. An easy way to check > would be to change the definition to: > > let stream_declarations : 'a. (internal_result,'a) result_stream = > ... > > or > > let stream_declarations : type a. (internal_result,a) result_stream = > ... > > both of which enforce polymorphism, and so will give an error if your > definition is actually monomorphic. > > If `stream_declarations` does have the monomorphic type > `(internal_result, '_a) result_stream` then any attempt to use it as > `(internal_result, b) result_stream` would cause `b` to be unified with > `'_a` and thus escape it's scope. > > Regards, > > Leo > -- gregory malecha --001a11c24b38d07ce1052f0c4da0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Leo --

This is exactly what I n= eeded to know. I thought that the (type a) annotation was forcing the funct= ion to be polymorphic. For future reference, is there any way to write the = annotation (that forces the function to be polymorphic) without having to w= rite explicit 'fun's?

Thanks.
<= div class=3D"gmail_extra">
On Sun, Mar 27, 20= 16 at 12:04 AM, Leo White <leo@lpw25.net> wrote:
This is a guess since you didn't include the definit= ion of
stream_declarations, but I suspect that:

> (* I have the following function, which seems to type check *)
> let stream_declarations (type a)
> : (internal_result,a) result_stream =3D ...

is not polymorphic. The `(type a)` annotation ensures that `a` is
abstract in the body of `stream_declarations` but does not enforce
that the result is polymorphic -- in particular I suspect that you
are running up against the value restriction. An easy way to check
would be to change the definition to:

=C2=A0 let stream_declarations : 'a. (internal_result,'a) result_st= ream =3D
=C2=A0 ...

or

=C2=A0 let stream_declarations : type a. (internal_result,a) result_stream = =3D
=C2=A0 ...

both of which enforce polymorphism, and so will give an error if your
definition is actually monomorphic.

If `stream_declarations` does have the monomorphic type
`(internal_result, '_a) result_stream` then any attempt to use it as
`(internal_result, b) result_stream` would cause `b` to be unified with
`'_a` and thus escape it's scope.

Regards,

Leo



--
gregory malecha
--001a11c24b38d07ce1052f0c4da0--