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 3B6277FBFE for ; Sat, 24 Jan 2015 04:47:14 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of jordojw@gmail.com) identity=pra; client-ip=209.85.215.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="jordojw@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of jordojw@gmail.com designates 209.85.215.49 as permitted sender) identity=mailfrom; client-ip=209.85.215.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="jordojw@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-la0-f49.google.com) identity=helo; client-ip=209.85.215.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="postmaster@mail-la0-f49.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoCAIYVw1TRVdcxm2dsb2JhbABaDoNKXYJ8w1GFbwKBDwdDAQEBAQERAQEBAQEGCwsJFC6EDAEBAQMBEhEdARsdAQMBCwYDAgsNKgICIgERAQUBHAYTCBqHdQEDCQgNoH+QTz4xiy6Ba4J3ihIKGScNVIQ7AQEBAQEBAQEBAQEBAQEBAQEBFAEFDo8RCAEBSwQHgmiBQQWKBYgySIMWgXiBFRAmgkmGM4YrEiOBDAmDU14dMQWBBoE3AQEB X-IPAS-Result: AkoCAIYVw1TRVdcxm2dsb2JhbABaDoNKXYJ8w1GFbwKBDwdDAQEBAQERAQEBAQEGCwsJFC6EDAEBAQMBEhEdARsdAQMBCwYDAgsNKgICIgERAQUBHAYTCBqHdQEDCQgNoH+QTz4xiy6Ba4J3ihIKGScNVIQ7AQEBAQEBAQEBAQEBAQEBAQEBFAEFDo8RCAEBSwQHgmiBQQWKBYgySIMWgXiBFRAmgkmGM4YrEiOBDAmDU14dMQWBBoE3AQEB X-IronPort-AV: E=Sophos;i="5.09,458,1418079600"; d="scan'208";a="97531911" Received: from mail-la0-f49.google.com ([209.85.215.49]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 24 Jan 2015 04:47:06 +0100 Received: by mail-la0-f49.google.com with SMTP id gf13so682369lab.8 for ; Fri, 23 Jan 2015 19:47:06 -0800 (PST) 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=Lny8H5DMFwjnLeFsqoWQ8nvz6wEg9GbJgUE5votM0HM=; b=yTuaOPwW49GIxbVJ8hIUeuTBh/iJlZ0JAJv7N6n9heYOXTuXLr4kUVEC19gpdWj/eq F0sn9Dfk7nEDnY7QL9sz8SSdkxSDUqO0umPZZQn3MPrzgrF6FTJrK3O2cn9N0IPVHsVa N77L5mB/+xicJqBfDQhcZH5iZNlEasR7fMX4wmhNhm9/3UNuNO+XpYKR+I39QfWAAwCW z90R+4QaRoxBH7AgotPeAdAQrAGQKnvbRHZtDAWVxfI7YbmoELdSKXqQuByhkQpKX07o J1AzymTX3ZCncEsbbANu56qzGZE66Wtmhi4PAQRkMSZLBzZYOWrAPVUAYtQuyZmionsZ 1odQ== MIME-Version: 1.0 X-Received: by 10.152.4.200 with SMTP id m8mr10494699lam.17.1422071225871; Fri, 23 Jan 2015 19:47:05 -0800 (PST) Received: by 10.25.143.207 with HTTP; Fri, 23 Jan 2015 19:47:05 -0800 (PST) In-Reply-To: References: Date: Fri, 23 Jan 2015 19:47:05 -0800 Message-ID: From: Jordan W To: Jacques Garrigue Cc: Mailing List OCaml Content-Type: multipart/alternative; boundary=089e013d11524372e1050d5dc291 X-Validation-by: jordojw@gmail.com Subject: Re: [Caml-list] Explicit Arity with Polymorphic Variants --089e013d11524372e1050d5dc291 Content-Type: text/plain; charset=UTF-8 David Allsopp, could you please include me on the "Reply" so that the mail threads make their way to my inbox? David, are you certain that the explicit_arity attribute is only related to type declarations? I do not believe that to be the case. I understand them to apply to patterns and expressions as well. (* Declares a variant that accepts a *single* parameter *) type oneArgTuple = OneArg of (int*int) (* Works because arity is massaged into whatever is necessary and doesn't need to be expressed at parse time. *) let OneArg (x,y) = OneArg (1,2) (* But you can *explicitly* enforce arity and tell the type system that this tuple should be treated as multiple arguments *) (* That causes this to fail type checking on this tuple pattern! *) let (OneArg (x,y) [@explicit_arity]) = OneArg (1,2);; >> Error: The constructor OneArg expects 1 argument(s), >> but is applied here to 2 argument(s) (* Similarly, at parse time, you can tell the parser to parse an expression as being multiple arguments *) let result = OneArg (1,2)[@explicit_arity];; >> Error: The constructor OneArg expects 1 argument(s), >> but is applied here to 2 argument(s) So the fact that you can inform the parser to treat a tuple as multiple arguments to a Constructor, means that the same should be true of polymorphic variants, but it is not. For example, this type checks but it shouldn't: let (`MyThing (x,y) [@explicit_arity]) = `MyThing (2,2);; On Fri, Jan 23, 2015 at 12:03 AM, Jacques Garrigue < garrigue@math.nagoya-u.ac.jp> wrote: > The answer is simple: polymorphic variants can only accept one argument > (which may of course be a tuple). The other behavior would have required > a specific syntax for multi-parameter polymorphic variants, since there is > no information associated to the constructor for them. > > Jacques Garrigue > > On 2015/01/23 15:53, Jordan W wrote: > > > > The OCaml compiler allows distinguishing between variants that accept a > single tuple and variant types that accept several parameters. What looks > like a variant type accepting a tuple, is actually the later: > > > > type x = TwoSeparateArguments of int * int > > let tuple = (10,10) > > let thisWontWork = TwoSeparateArguments tuple;; > > >> Error: The constructor TwoSeparateArguments expects 2 argument(s), > but is > applied here to 1 argument(s) > > > > (* Notice the extra parens around the two ints *) > > type x = OneArgumentThatIsATuple of (int * int) > > let thisActuallyWorks = OneArgumentThatIsATuple tuple > > > > The extra parens distinguish at type definition time which of the two is > intended. > > > > But OCaml does some automatic massaging of the data that you supply to > constructor values. > > let _ = OneArgumentThatIsATuple (4, 5) > > let _ = TwoSeparateArguments (4, 5) > > > > No extra parens are required in this case. But OCaml does give you the > ability to annotate patterns and expressions with an "explicit_arity" > attribute which allows syntactic distinction between supplying two separate > parameters vs. one that happens to be a tuple. This is important for other > parser extensions that wish to treat the two distinctly. What OCaml allows > (explicit_arity attribute) works well enough. > > > > The only problem is that there doesn't seem to be a way to utilize the > same explicit_arity attributes with polymorphic variants. Such attributes > are not acknowledged by the type system. Is this intended? > > > > Taking a quick look at typecore.ml, explicit_arity appears to be > acknowledged on standard constructors but not polymorphic variants. > > > https://github.com/ocaml/ocaml/blob/6e85c2d956c8fd5b45acd70a27586e44bb3a3119/typing/typecore.ml > > > > It seems these should be brought to consistency. I will file a mantis > issue unless anyone believes this is intended. > > > > Thank you in advance. > > > > Jordan > > > > > > > --089e013d11524372e1050d5dc291 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
David Allsopp, could you please include me on the "Re= ply" so that the mail threads make their way to my inbox?

David, are you certain that the explicit_arity attribute is only rel= ated to type declarations? I do not believe that to be the case. I understa= nd them to apply to patterns and expressions as well.

<= div>(* Declares a variant that accepts a *single* parameter *)
ty= pe oneArgTuple =3D OneArg of (int*int)

(* Work= s because arity is massaged into whatever is necessary and doesn't need= to be expressed at parse time. *)
let OneArg (x,y) =3D OneArg (1= ,2)

(* But you can *explicitly* enforce arity = and tell the type system that this tuple should be treated as multiple argu= ments *)
(* That causes this to fail type checking on this tuple = pattern! *)
let (OneArg (x,y) [@explicit_arity]) =3D OneArg = (1,2);;
>> Error: The constructor OneArg expects 1 argument= (s),
>> but is applied here to 2 argument(s)

(* Similarly, at parse time, you can tell the parser to pa= rse an expression as being multiple arguments *)
let result = =3D OneArg (1,2)[@explicit_arity];;
>> Error: The construct= or OneArg expects 1 argument(s),
>> but is applied here to = 2 argument(s)

So the fact that you can infor= m the parser to treat a tuple as multiple arguments to a Constructor, means= that the same should be true of polymorphic variants, but it is not. For e= xample, this type checks but it shouldn't:

=C2= =A0let (`MyThing (x,y) [@explicit_arity]) =3D `MyThing (2,2);;

On Fri, Jan 23,= 2015 at 12:03 AM, Jacques Garrigue <garrigue@math.nagoya-u.ac.= jp> wrote:
The answer is simple: polymorp= hic variants can only accept one argument
(which may of course be a tuple). The other behavior would have required
a specific syntax for multi-parameter polymorphic variants, since there is<= br> no information associated to the constructor for them.

Jacques Garrigue

On 2015/01/23 15:53, Jordan W wrote:
>
> The OCaml compiler allows distinguishing between variants that accept = a single tuple and variant types that accept several parameters. What looks= like a variant type accepting a tuple, is actually the later:
>
> type x =3D TwoSeparateArguments of int * int
> let tuple =3D (10,10)
> let thisWontWork =3D TwoSeparateArguments tuple;;
> >> Error: The constructor TwoSeparateArguments expects 2 argumen= t(s),=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 but is applied here to 1 argument(s)
>
> (* Notice the extra parens around the two ints *)
> type x =3D OneArgumentThatIsATuple of (int * int)
> let thisActuallyWorks =3D OneArgumentThatIsATuple tuple
>
> The extra parens distinguish at type definition time which of the two = is intended.
>
> But OCaml does some automatic massaging of the data that you supply to= constructor values.
> let _ =3D OneArgumentThatIsATuple (4, 5)
> let _ =3D TwoSeparateArguments (4, 5)
>
> No extra parens are required in this case. But OCaml does give you the= ability to annotate patterns and expressions with an "explicit_arity&= quot; attribute which allows syntactic distinction between supplying two se= parate parameters vs. one that happens to be a tuple. This is important for= other parser extensions that wish to treat the two distinctly. What OCaml = allows (explicit_arity attribute) works well enough.
>
> The only problem is that there doesn't seem to be a way to utilize= the same explicit_arity attributes with polymorphic variants. Such attribu= tes are not acknowledged by the type system. Is this intended?
>
> Taking a quick look at typecore.ml, explicit_arity appears to be acknowledged on standard co= nstructors but not polymorphic variants.
> https://github.com/= ocaml/ocaml/blob/6e85c2d956c8fd5b45acd70a27586e44bb3a3119/typing/typecore.m= l
>
> It seems these should be brought to consistency. I will file a mantis = issue unless anyone believes this is intended.
>
> Thank you in advance.
>
> Jordan
>
>



--089e013d11524372e1050d5dc291--