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 2CBE47EE48 for ; Sun, 25 Jan 2015 09:02:58 +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.217.172; 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.217.172 as permitted sender) identity=mailfrom; client-ip=209.85.217.172; 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-lb0-f172.google.com) identity=helo; client-ip=209.85.217.172; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="postmaster@mail-lb0-f172.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosBADuixFTRVdmsm2dsb2JhbABagkOBFU4LBIJ8wzyFbwKBCAdDAQEBAQERAQEBAQEGCwsJFC6EDAEBAQMBEhEdARsdAQMBCwYFCw0qAgIhAQERAQUBHAYTIod1AQMJCA2xSD4xiy6Ba4J3iTQKGScNVIQ7AQEBAQEBAQMBAQEBAQEBARQBBQ6NQIImBAeCaIFBBYoHiDKDXjOBRYElJoh8gX+ELBIjgQwJhDEdMQWCPQEBAQ X-IPAS-Result: AosBADuixFTRVdmsm2dsb2JhbABagkOBFU4LBIJ8wzyFbwKBCAdDAQEBAQERAQEBAQEGCwsJFC6EDAEBAQMBEhEdARsdAQMBCwYFCw0qAgIhAQERAQUBHAYTIod1AQMJCA2xSD4xiy6Ba4J3iTQKGScNVIQ7AQEBAQEBAQMBAQEBAQEBARQBBQ6NQIImBAeCaIFBBYoHiDKDXjOBRYElJoh8gX+ELBIjgQwJhDEdMQWCPQEBAQ X-IronPort-AV: E=Sophos;i="5.09,463,1418079600"; d="scan'208";a="97607615" Received: from mail-lb0-f172.google.com ([209.85.217.172]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 25 Jan 2015 09:02:56 +0100 Received: by mail-lb0-f172.google.com with SMTP id l4so3560230lbv.3 for ; Sun, 25 Jan 2015 00:02:56 -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=Mt+nR0hXTqlyyTKl6xaTwoWjV+NgTwWBJdXUEbcWyII=; b=B+NZRzy0PV4u6pns8gcwuH1tzuny5nnRq0DapDUjn83H6QWsDjjsZpSWnu5XaCT8Ec pcwfyVxpL2rDAEOLtShBDz9JNMmTi5GD2fvdyFENuqFSgQL9I+kizNqXYqf74JEL5nUy /nx6SxDsd1lzt1K+bLCly4Gaw3lYdfsL7Ravfe9VT3w5/ioxruo6hScFo77zrXHygVLx QN/XPidXKIUtDyuzvQo9ebAq4T5JxsKA7xvARtPwz1aIr2djI25cSEL4+6htoCMs90bm 9pJ3a2+6CQ4285vo+dI0kbI91OlW65kd9cjzBlwoWZ79hLpipaxgcAXBXrRsToPGSu5G QpIA== MIME-Version: 1.0 X-Received: by 10.112.156.169 with SMTP id wf9mr15508458lbb.85.1422172976077; Sun, 25 Jan 2015 00:02:56 -0800 (PST) Received: by 10.25.143.207 with HTTP; Sun, 25 Jan 2015 00:02:56 -0800 (PST) In-Reply-To: References: Date: Sun, 25 Jan 2015 00:02:56 -0800 Message-ID: From: Jordan W To: Gabriel Scherer Cc: Jacques Garrigue , Mailing List OCaml Content-Type: multipart/alternative; boundary=001a11c240b00c622b050d7573f1 X-Validation-by: jordojw@gmail.com Subject: Re: [Caml-list] Explicit Arity with Polymorphic Variants --001a11c240b00c622b050d7573f1 Content-Type: text/plain; charset=UTF-8 It sounds like this has nothing to do with polymorphic variants not requiring a type definition. I agree it's an ugly hack, but one that seems to accomplish something of value. There are two distinctions that I know of between single argument tuple constructors and mult-argument constructors: 1. Memory layout is different (Is this still the case)? 2. First-classness of arguments is different. With a single argument tuple, the contents can be passed around and then finally placed into the constructor without any overhead of destructuring/restructuring. Both of these seem like desirable controls to have and possibly justifies the existence of having two modes. Under that assumption, having some way to designate in the parse tree which is intended (at the pattern or expression level) seems like a good idea - and even if that mechanism is the ugly `explicit_arity` hack. So I understand the justification for the current state of the world. I'm curious why there is not some way to achieve the same with polymorphic variants (even if that is also a hack). Are you saying it was simply because time has not permitted it? Looking deeper, it seems polymorphic variants are incapable of accepting multiple arguments and only ever accept a single tuple (which is therefore allowed to be first class). I do wish OCaml used the revised syntax's syntactic distinction between the two modes which is what I'm currently experimenting with. On Sat, Jan 24, 2015 at 12:52 AM, Gabriel Scherer wrote: > explicit_arity is an ugly hack. It is used by camlp[45] (whose revised > syntax has a superior currified constructor-parameter syntax and is > thus never confused about arities) to convert its internal AST into > the OCaml parse tree. It is not meant to be used by end-users, only by > camlp5 as a code-producing tool. > > You ask why this was not extended to polymorphic variant. There was no > need, so nobody worked on it. Besides, I suspect making polymorphic > variant more complex is a bad idea -- and am quite certain relying on > an attribute there is a bad idea. > > > On Fri, Jan 23, 2015 at 10:04 AM, 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 > > 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 > > 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 > >> > > >> > > >> > >> > > > --001a11c240b00c622b050d7573f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It sounds like this has noth= ing to do with polymorphic variants not requiring a type definition.
<= div style=3D"font-size:13px">
I agr= ee it's an ugly hack, but one that seems to accomplish something of val= ue. There are two distinctions that I know of between single argument tuple= constructors and mult-argument constructors:

1. Memory layout is differen= t (Is this still the case)?
2. First-cla= ssness of arguments is different. With a single argument tuple, the content= s can be passed around and then finally placed into the constructor without= any overhead of destructuring/restructuring.

Both of these seem like desir= able controls to have and possibly justifies the existence of having two mo= des.
Under that assumption, having some = way to designate in the parse tree which is intended (at the pattern or exp= ression level) seems like a good idea - and even if that mechanism is the u= gly `explicit_arity` hack. So I understand the justification for the curren= t state of the world. I'm curious why there is not some way to achieve = the same with polymorphic variants (even if that is also a hack). Are you s= aying it was simply because time has not permitted it? Looking deeper, it s= eems polymorphic variants are incapable of accepting multiple arguments and= only ever accept a single tuple (which is therefore allowed to be first cl= ass).

I do wish OCaml used the revised syntax's syntactic distinction b= etween the two modes which is what I'm currently experimenting with.

On Sat, = Jan 24, 2015 at 12:52 AM, Gabriel Scherer <gabriel.scherer@gmail.c= om> wrote:
explicit_arity i= s an ugly hack. It is used by camlp[45] (whose revised
syntax has a superior currified constructor-parameter syntax and is
thus never confused about arities) to convert its internal AST into
the OCaml parse tree. It is not meant to be used by end-users, only by
camlp5 as a code-producing tool.

You ask why this was not extended to polymorphic variant. There was no
need, so nobody worked on it. Besides, I suspect making polymorphic
variant more complex is a bad idea -- and am quite certain relying on
an attribute there is a bad idea.


On Fri, Jan 23, 2015 at 10:04 AM, Jordan W <jordojw@gmail.com> wrote:
> My understanding was that this "explicit_arity" attribute al= lows precisely
> that - the capability to implement a specific syntax to distinguish be= tween
> multiple arguments and just one argument (that may coincidentally be a=
> tuple). My question is why this capability is not extended to polymorp= hic
> variants in the same way it has been extended to standard variant type= s.
>
> On Fri, Jan 23, 2015 at 12:03 AM, Jacques Garrigue
> <garrigue@math.nago= ya-u.ac.jp> wrote:
>>
>> The answer is simple: polymorphic variants can only accept one arg= ument
>> (which may of course be a tuple). The other behavior would have re= quired
>> 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 tha= t 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 argument(s),
>> > >> 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 giv= e you the
>> > ability to annotate patterns and expressions with an "ex= plicit_arity"
>> > attribute which allows syntactic distinction between supplyin= g two separate
>> > parameters vs. one that happens to be a tuple. This is import= ant 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 t= o utilize the
>> > same explicit_arity attributes with polymorphic variants. Suc= h 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 var= iants.
>> >
>> > https://gi= thub.com/ocaml/ocaml/blob/6e85c2d956c8fd5b45acd70a27586e44bb3a3119/typing/t= ypecore.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
>> >
>> >
>>
>>
>

--001a11c240b00c622b050d7573f1--