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 0C5797FBFE for ; Sat, 24 Jan 2015 09:52:54 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.223.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.223.174 as permitted sender) identity=mailfrom; client-ip=209.85.223.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@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-ie0-f174.google.com) identity=helo; client-ip=209.85.223.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ie0-f174.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUBABxcw1TRVd+ulGdsb2JhbABag1hZBIJ8w1OFbwKBCwdDAQEBAQERAQEBAQcLCwkSMIQNAQEEEhEdARsdAQMMBgULDQICJgICIQEBEQEFARwGEyKHdQEDEQ2xVT4xiy6Ba4J3igkKGScNVIQ7AQEBAQEBAQMBAQEBARcBAQQOgROMLYIqB4JogUEFkjmDXjOBRYEliSKBf4QsEiOBDAmEET0xBYI9AQEB X-IPAS-Result: ApUBABxcw1TRVd+ulGdsb2JhbABag1hZBIJ8w1OFbwKBCwdDAQEBAQERAQEBAQcLCwkSMIQNAQEEEhEdARsdAQMMBgULDQICJgICIQEBEQEFARwGEyKHdQEDEQ2xVT4xiy6Ba4J3igkKGScNVIQ7AQEBAQEBAQMBAQEBARcBAQQOgROMLYIqB4JogUEFkjmDXjOBRYEliSKBf4QsEiOBDAmEET0xBYI9AQEB X-IronPort-AV: E=Sophos;i="5.09,459,1418079600"; d="scan'208";a="97547223" Received: from mail-ie0-f174.google.com ([209.85.223.174]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 24 Jan 2015 09:52:53 +0100 Received: by mail-ie0-f174.google.com with SMTP id vy18so1421631iec.5 for ; Sat, 24 Jan 2015 00:52:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5lJzEJclOij3/kdhsD9R5FvQ3Uh0wzbWTyatrCR47Fc=; b=tjFYCLv8kqv7NBUv49GqIGY6v7sQB//MSJkQ5w8a0J5jWKwOwk3inhC7shLj0+94p0 ZcIUjq2OwX617MeBn9BZ+NEsOs2ydx2J+s/EEDSHdzfdMwye1IQUjByKeCyaQp47J9d3 AVY8aIw+AcAUG1D3FqpIsj7qoxW7ZbrGRJc4WtG4VDsl5ukgV8dCNF04Ti13tSaNd5Pq DfwPNZEjyCFB94VdCr6nu0dcOcqyAzi6klEXD9qBnHgYgDuxaIAvtoWt/oa7cSi453x/ SPLeAAAltrOq+r5ms4CxCHzCTaShcDOm/mULRMKr1WAQBeVmrD7Ey9KUwtfPI2L1raeL 07WA== X-Received: by 10.107.17.94 with SMTP id z91mr8354440ioi.76.1422089571804; Sat, 24 Jan 2015 00:52:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.12.133 with HTTP; Sat, 24 Jan 2015 00:52:11 -0800 (PST) In-Reply-To: References: From: Gabriel Scherer Date: Sat, 24 Jan 2015 09:52:11 +0100 Message-ID: To: Jordan W Cc: Jacques Garrigue , Mailing List OCaml Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Explicit Arity with Polymorphic Variants 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 >> > >> > >> >> >