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 889027FBFE for ; Fri, 23 Jan 2015 10:04:58 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jordojw@gmail.com) identity=pra; client-ip=209.85.215.44; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="jordojw@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of jordojw@gmail.com designates 209.85.215.44 as permitted sender) identity=mailfrom; client-ip=209.85.215.44; receiver=mail2-smtp-roc.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 (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-la0-f44.google.com) identity=helo; client-ip=209.85.215.44; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="postmaster@mail-la0-f44.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsBAGINwlTRVdcslGdsb2JhbABaDoNKWASCfMNPhTY5AoELB0MBAQEBAREBAQEBBwsLCRIwhAwBAQEDARIRHQEbHQEDAQsGAwILDSoCAiIBEQEFARwGEwgah3UBAwkIDaEgkE8+MYsugWuCd4pEChknDVSEEQEBAQEBAQEBAQEBAQEBAQEBARQBBQ6PZgQHgmiBQQWKAIgwg1iBd4EkJoh7hiYSI4EMCYNTXh0xBYI+AQEB X-IPAS-Result: AlsBAGINwlTRVdcslGdsb2JhbABaDoNKWASCfMNPhTY5AoELB0MBAQEBAREBAQEBBwsLCRIwhAwBAQEDARIRHQEbHQEDAQsGAwILDSoCAiIBEQEFARwGEwgah3UBAwkIDaEgkE8+MYsugWuCd4pEChknDVSEEQEBAQEBAQEBAQEBAQEBAQEBARQBBQ6PZgQHgmiBQQWKAIgwg1iBd4EkJoh7hiYSI4EMCYNTXh0xBYI+AQEB X-IronPort-AV: E=Sophos;i="5.09,453,1418079600"; d="scan'208";a="118281604" Received: from mail-la0-f44.google.com ([209.85.215.44]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 23 Jan 2015 10:04:57 +0100 Received: by mail-la0-f44.google.com with SMTP id s18so264524lam.3 for ; Fri, 23 Jan 2015 01:04:57 -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=/A327sox/pN0LoLMlCFqsjrAMbuK5rcYzm/6ZtmIbx4=; b=tqhlFLVOR9qedsDo13KtXG6SAUKGlxSp0SL++/VgTUM7qE+on/wBdgEO/4I8LMchhA DoIwXoSE46u2luuQPdTax2siTSxFy5qNKsDe6n+l+FcDRjiQ7bvGCULqSnxANaqpF76f 5Hdu5c8cIVKcr8RIUaTxuqN2Ko4jcQjXo9MUpq/mTh4GmONW4c9396TwrxyOtUEQ+yjd projziy1m8IU7c9vKPPMl04wjyaepEZGIPcbv9g0ZICZOx+Yz4+emF3rrU4ARkVE7voO v5iYjW6g0+ZYy+aAuJYs+l1N8n37jBklPuovGU3h28fM8YxzgP/u1wAIwO0tzxR8NZkU ynfQ== MIME-Version: 1.0 X-Received: by 10.112.118.144 with SMTP id km16mr3447966lbb.75.1422003897177; Fri, 23 Jan 2015 01:04:57 -0800 (PST) Received: by 10.25.143.207 with HTTP; Fri, 23 Jan 2015 01:04:57 -0800 (PST) In-Reply-To: References: Date: Fri, 23 Jan 2015 01:04:57 -0800 Message-ID: From: Jordan W To: Jacques Garrigue Cc: Mailing List OCaml Content-Type: multipart/alternative; boundary=047d7bfd07e6291ca6050d4e1533 X-Validation-by: jordojw@gmail.com Subject: Re: [Caml-list] Explicit Arity with Polymorphic Variants --047d7bfd07e6291ca6050d4e1533 Content-Type: text/plain; charset=UTF-8 My understanding was that this "explicit_arity" attribute allows precisely that - the capability to implement a specific syntax to distinguish between multiple arguments and just one argument (that may coincidentally be a tuple). My question is why this capability is not extended to polymorphic variants in the same way it has been extended to standard variant types. 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 > > > > > > > --047d7bfd07e6291ca6050d4e1533 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My understanding was that this "explicit_arity" = attribute allows precisely that - the capability to implement a specific sy= ntax to distinguish between multiple arguments and just one argument (that = may coincidentally be a tuple). My question is why this capability is not e= xtended to polymorphic variants in the same way it has been extended to sta= ndard variant types.

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 on= e 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
>
>



--047d7bfd07e6291ca6050d4e1533--