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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id 58B647EEDB for ; Sun, 28 Oct 2012 20:46:25 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of rathereasy@gmail.com) identity=pra; client-ip=209.85.214.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="rathereasy@gmail.com"; x-sender="rathereasy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of rathereasy@gmail.com designates 209.85.214.182 as permitted sender) identity=mailfrom; client-ip=209.85.214.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="rathereasy@gmail.com"; x-sender="rathereasy@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ob0-f182.google.com) identity=helo; client-ip=209.85.214.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="rathereasy@gmail.com"; x-sender="postmaster@mail-ob0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsCAKaKjVDRVda2k2dsb2JhbABDsEmJKgGIZAgjAQEBAQkJFBQEI4IeAQEBAwESAhMZARsSCwEDAQsGBQQHAxchIgERAQUBChIGExIQh1EBAwkGC5wjYgkDjDCCdoN+ChknAwpZiHUBBQyLaYZdA4hZjRuBGo1HFimEMQ X-IronPort-AV: E=Sophos;i="4.80,667,1344204000"; d="scan'208";a="160688262" Received: from mail-ob0-f182.google.com ([209.85.214.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 28 Oct 2012 20:46:24 +0100 Received: by mail-ob0-f182.google.com with SMTP id wc20so7033065obb.27 for ; Sun, 28 Oct 2012 12:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kR/ijDOAmm7oEnFvb4Yez+CFuPfe39Lxq3b0+ybLA6k=; b=LsjCjwnp4SFi0flDp7qLLEAViOKNedlBj1D+SmB7q0xTP1Re0uur1ro9wMhpihT34I PXFOKQFlCJNC+Q+tx6jT8T2KV6eRMFKsh1f16534conYHCom4TQ0reiPnT2Z6vwRg8V7 ujq7+wXZD45XyASCPdO0j7TO2ZVq6No8m7+emQYiH8dNpyLKPwbv/Hf8PJsu+rhnhAWE HZBkHn+TphwVMRF9/i4HLblRisyNRfjhWYtX4jfBYKE0dYrxGN1KTYEsQmS4IogtNVL0 r9/L6Am7JDNPy+TZIzHLu9DjKtuBRNA7JoOGm4yJRYRMxwg75X5xHxEmEeA3NmqKmDKy /dOA== MIME-Version: 1.0 Received: by 10.182.221.97 with SMTP id qd1mr22709028obc.6.1351453583050; Sun, 28 Oct 2012 12:46:23 -0700 (PDT) Received: by 10.76.97.107 with HTTP; Sun, 28 Oct 2012 12:46:22 -0700 (PDT) Received: by 10.76.97.107 with HTTP; Sun, 28 Oct 2012 12:46:22 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Oct 2012 12:46:22 -0700 Message-ID: From: Jacques Le Normand To: Yaron Minsky Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=f46d0446325cbf876904cd23ceb1 Subject: Re: [Caml-list] explaining polymorphic variants --f46d0446325cbf876904cd23ceb1 Content-Type: text/plain; charset=ISO-8859-1 Well, for one, the patterns are typed independently of the type of the guard. For two, this wouldn't work for nested patterns. Do we want to make an exception for the case when there are only simple patterns and when the type of the guard has been fully determined? I don't know if it's worth the trouble, especially when it can usually be handled with the # operator. On Oct 28, 2012 6:50 AM, "Yaron Minsky" wrote: > A question that came up in the section of Real World OCaml on > polymorphic variants. > > I'm wondering if someone can explain the error in the third definition > below. > > # let handle_a `A = "a";; > val handle_a : [< `A ] -> string = > # let handle_ab (x: [`A | `B ]) = > match x with > |`B -> "b" > | `A as a -> handle_a a > ;; > val handle_ab : [ `A | `B ] -> string = > # let handle_ab' (x: [`A | `B ]) = > match x with > | `B -> "b" > | a -> handle_a a > ;; > Characters 86-87: > | a -> handle_a a > ^ > Error: This expression has type [ `A | `B ] > but an expression was expected of type [< `A ] > The second variant type does not allow tag(s) `B > > I understand roughly what's going on here. In the definition of > handle_ab, there is a straightforward syntactic basis for narrowing > the type of the variable a. In the case of handle_ab', that syntactic > basis is no longer available, and so the type of a is not narrowed. > > But the question is: why isn't it narrowed based on the other > information available? It seems in theory possible to infer the > narrower type in this case. Does anyone have a satisfying explanation > as to why? > > y > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --f46d0446325cbf876904cd23ceb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Well, for one, the patterns are typed independently of the type of the g= uard. For two, this wouldn't work for nested patterns.
Do we want to make an exception for the case when there are only simple pat= terns and when the type of the guard has been fully determined? I don't= know if it's worth the trouble, especially when it can usually be hand= led with the # operator.

On Oct 28, 2012 6:50 AM, "Yaron Minsky"= ; <yminsky@janestreet.com&= gt; wrote:
A question that came up in the section of Real World OCaml on
polymorphic variants.

I'm wondering if someone can explain the error in the third definition<= br> below.

=A0 =A0 # let handle_a `A =3D "a";;
=A0 =A0 val handle_a : [< `A ] -> string =3D <fun>
=A0 =A0 # let handle_ab (x: [`A | `B ]) =A0=3D
=A0 =A0 =A0 =A0 match x with
=A0 =A0 =A0 =A0 |`B -> "b"
=A0 =A0 =A0 =A0 | `A as a -> handle_a a
=A0 =A0 =A0 ;;
=A0 =A0 val handle_ab : [ `A | `B ] -> string =3D <fun>
=A0 =A0 # let handle_ab' (x: [`A | `B ]) =A0=3D
=A0 =A0 =A0 =A0 match x with
=A0 =A0 =A0 =A0 | `B -> "b"
=A0 =A0 =A0 =A0 | a -> handle_a a
=A0 =A0 =A0 ;;
=A0 =A0 Characters 86-87:
=A0 =A0 =A0 =A0 | a -> handle_a a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^
=A0 =A0 Error: This expression has type [ `A | `B ]
=A0 =A0 =A0 =A0 =A0 =A0but an expression was expected of type [< `A ]
=A0 =A0 =A0 =A0 =A0 =A0The second variant type does not allow tag(s) `B

I understand roughly what's going on here. =A0In the definition of
handle_ab, there is a straightforward syntactic basis for narrowing
the type of the variable a. =A0In the case of handle_ab', that syntacti= c
basis is no longer available, and so the type of a is not narrowed.

But the question is: why isn't it narrowed based on the other
information available? =A0It seems in theory possible to infer the
narrower type in this case. =A0Does anyone have a satisfying explanation
as to why?

y

--
Caml-list mailing list. =A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
--f46d0446325cbf876904cd23ceb1--