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 BA40B7FBFE for ; Fri, 23 Jan 2015 10:56:42 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dra-news@metastack.com) identity=pra; client-ip=62.13.149.78; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of dra-news@metastack.com designates 62.13.149.78 as permitted sender) identity=mailfrom; client-ip=62.13.149.78; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.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@outmail149078.authsmtp.net) identity=helo; client-ip=62.13.149.78; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="postmaster@outmail149078.authsmtp.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcBAIkZwlQ+DZVOnGdsb2JhbABagmR0WLQCBpJJhTY5AoEUQwEBAQEBEQEBAQEBCBQJQoQNAQUDgQYCAQgYJwchERQRAgQTiBgDEgMJzXoNhGUBAQgBAQEBAQEchgSHSoImC4MWgRMFkjCDWDOCaCaIe4F+hXKEEG8Fgj4BAQE X-IPAS-Result: AjcBAIkZwlQ+DZVOnGdsb2JhbABagmR0WLQCBpJJhTY5AoEUQwEBAQEBEQEBAQEBCBQJQoQNAQUDgQYCAQgYJwchERQRAgQTiBgDEgMJzXoNhGUBAQgBAQEBAQEchgSHSoImC4MWgRMFkjCDWDOCaCaIe4F+hXKEEG8Fgj4BAQE X-IronPort-AV: E=Sophos;i="5.09,453,1418079600"; d="scan'208,217";a="97442547" Received: from outmail149078.authsmtp.net ([62.13.149.78]) by mail3-smtp-sop.national.inria.fr with ESMTP; 23 Jan 2015 10:56:41 +0100 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t0N9uenx073048 for ; Fri, 23 Jan 2015 09:56:40 GMT Received: from romulus.metastack.com (cpc1-cmbg5-0-0-cust241.5-4.cable.virginm.net [81.98.252.242]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t0N9ucME054635 for ; Fri, 23 Jan 2015 09:56:38 GMT Received: from remus.metastack.local (remus.metastack.com [172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id t0N9ucOu024565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 23 Jan 2015 09:56:38 GMT Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.03.0224.002; Fri, 23 Jan 2015 09:56:38 +0000 From: David Allsopp To: Mailing List OCaml Thread-Topic: [Caml-list] Explicit Arity with Polymorphic Variants Thread-Index: AQHQNtl6Q25l7W7x0U2j9Jk6Y2jO25zNWHSAgAARKoCAAA5xrg== Date: Fri, 23 Jan 2015 09:56:37 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_B67D4E053D6D41CE871EBB1E361EE084metastackcom_" MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-Server-Quench: 2009a2d7-a2e6-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZZVg1f DC4bFwdFRBksPQFF ChxFJgxfNlEAUAAU NkdBMnJSNkcdTBdX QSgJWEsuAQNuW2N0 bhpRZA9YZEBNVkti UVZASkxQEQd2AxgD GRwbTRk8MwU4cTsj GDNiW3RdX0E0dEZ9 S0kaF20GbDZiPGcC AUINcR5VcVZOYxYT bVRiVHMPZGwHN3tj QgNoKQo8b31sAy1Q RkQJLEkOdA4mDiY4 RhsDAX0GB0wZVm0s LgAmYmYbGFcUNV8q MVoqEWwRKR4bDBFF dwAA X-Authentic-SMTP: 61633634383431.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 81.98.252.242/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Subject: Re: [Caml-list] Explicit Arity with Polymorphic Variants --_000_B67D4E053D6D41CE871EBB1E361EE084metastackcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A regular constructor has a type definition which is where explicit_arity i= s defined, i.e. it's inferred from either type t =3D Foo of int * int or type t =3D Foo of (int * int) which allows you to determine what Foo(42, 42) actually means. Polymorphic variants have no type definition so, without a new syntax *for = the values*, you can only have one interpretation. Requiring a type definit= ion for polymorphic variants would defeat their purpose! David On 23 Jan 2015, at 09:06, Jordan W > wrote: 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 tup= le). My question is why this capability is not extended to polymorphic vari= ants in the same way it has been extended to standard variant types. On Fri, Jan 23, 2015 at 12:03 AM, Jacques Garrigue > 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 s= ingle tuple and variant types that accept several parameters. What looks li= ke 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 argument(s), = but is applie= d 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 co= nstructor 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 ab= ility to annotate patterns and expressions with an "explicit_arity" attribu= te which allows syntactic distinction between supplying two separate parame= ters 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 (expli= cit_arity attribute) works well enough. > > The only problem is that there doesn't seem to be a way to utilize the sa= me 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 ap= pears to be acknowledged on standard constructors but not polymorphic varia= nts. > https://github.com/ocaml/ocaml/blob/6e85c2d956c8fd5b45acd70a27586e44bb3a3= 119/typing/typecore.ml > > It seems these should be brought to consistency. I will file a mantis iss= ue unless anyone believes this is intended. > > Thank you in advance. > > Jordan > > --_000_B67D4E053D6D41CE871EBB1E361EE084metastackcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
A regular constructor has a type definition which is where explicit_ar= ity is defined, i.e. it's inferred from either

type t =3D Foo of int * int

or

type t =3D Foo of (int * int)

which allows you to determine what Foo(42, 42) actually means.

Polymorphic variants have no type definition so, without a new syntax = *for the values*, you can only have one interpretation. Requiring a type de= finition for polymorphic variants would defeat their purpose!


David



On 23 Jan 2015, at 09:06, Jordan W <jordojw@gmail.com> wrote:

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 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 Garrig= ue <garri= gue@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<= 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),                    =                      = ;                     &nb= sp;   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 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 co= nstructors but not polymorphic variants.
> https://github.com/ocaml/ocaml/blob/6e85c2d956c8fd5b45acd70a27586e44bb3a311= 9/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
>
>



--_000_B67D4E053D6D41CE871EBB1E361EE084metastackcom_--