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 655587EEFA for ; Mon, 9 Nov 2015 21:32:37 +0100 (CET) IronPort-PHdr: 9a23:7mqKJhx0SiU7CkPXCy+O+j09IxM/srCxBDY+r6Qd0OoeIJqq85mqBkHD//Il1AaPBtWGra4fwLON7+jJYi8p39WoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd6PyZjsnLnpp9X6WEZhunmUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD89pozcNLUL37cqIkVvQYSW1+ayFm0vb2rgHORhej4X4VU2Ne0kYZQluN0BavcZ77qCr3sqJG0ymXJ8DsBeQ7UD647qpvDgTjiCodOiQR/2Tei8g2h6Ve9kGPvRt6lqfQaYCTfNRkf7jWfZtOTG5IX8AXWTZAGYi8R48CH+sPPKBTqIyr9AhGlge3GQT5XLCn8TRPnHKjmPBj3g== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=alain.frisch@lexifi.com; spf=None smtp.mailfrom=alain.frisch@lexifi.com; spf=None smtp.helo=postmaster@mx30.yaziba.net Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain.frisch@lexifi.com) identity=pra; client-ip=82.138.71.21; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="alain.frisch@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alain.frisch@lexifi.com) identity=mailfrom; client-ip=82.138.71.21; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="alain.frisch@lexifi.com"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mx30.yaziba.net) identity=helo; client-ip=82.138.71.21; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="alain.frisch@lexifi.com"; x-sender="postmaster@mx30.yaziba.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BzAABlAUFWnBVHilJehA5vrm+RQCGFbwKBRTwQAQEBAQEBAQEQAQEBAQEICwkJIS6CLoIHAQEBAwEjBBE2CgEQCxgCAgUEEgsCAgkDAgECATMSBg0GAgEBDogHAwoMCbB6jAwDhFMBAQEBAQEEAQEBAQEBHYEBhVOEfod1gUQFhgsMkDGFHogJgVtJg3eDApMmAjiCUoFecYVmAQEB X-IPAS-Result: A0BzAABlAUFWnBVHilJehA5vrm+RQCGFbwKBRTwQAQEBAQEBAQEQAQEBAQEICwkJIS6CLoIHAQEBAwEjBBE2CgEQCxgCAgUEEgsCAgkDAgECATMSBg0GAgEBDogHAwoMCbB6jAwDhFMBAQEBAQEEAQEBAQEBHYEBhVOEfod1gUQFhgsMkDGFHogJgVtJg3eDApMmAjiCUoFecYVmAQEB X-IronPort-AV: E=Sophos;i="5.20,267,1444687200"; d="scan'208";a="186818499" Received: from mx30.yaziba.net ([82.138.71.21]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 09 Nov 2015 21:32:36 +0100 Received: from mta20.int.yaziba.net (unknown [217.117.151.14]) by mx30.yaziba.net (mx10.yaziba.net) with ESMTP id 06AB61A7581; Mon, 9 Nov 2015 21:32:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mta20.int.yaziba.net (Postfix) with ESMTP id 0E9FC149785; Mon, 9 Nov 2015 21:32:36 +0100 (CET) X-Virus-Scanned: amavisd-new at mta20.int.yaziba.net Received: from mta20.int.yaziba.net ([127.0.0.1]) by localhost (mta20.int.yaziba.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3keILHhGfl6E; Mon, 9 Nov 2015 21:32:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mta20.int.yaziba.net (Postfix) with ESMTP id DA69E149786; Mon, 9 Nov 2015 21:32:35 +0100 (CET) X-Virus-Scanned: amavisd-new at mta20.int.yaziba.net Received: from mta20.int.yaziba.net ([127.0.0.1]) by localhost (mta20.int.yaziba.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BFKtGKz3IPyg; Mon, 9 Nov 2015 21:32:35 +0100 (CET) Received: from [192.168.1.21] (APuteaux-655-1-112-37.w83-204.abo.wanadoo.fr [83.204.235.37]) by mta20.int.yaziba.net (Postfix) with ESMTPSA id 5416E149785; Mon, 9 Nov 2015 21:32:35 +0100 (CET) To: Gabriel Scherer References: <0F7D3B1B3C4B894D824F5B822E3E5A172CE3E070@IRSMSX102.ger.corp.intel.com> <87pozk6vjp.fsf@mid.deneb.enyo.de> <0F7D3B1B3C4B894D824F5B822E3E5A172CE3E747@IRSMSX102.ger.corp.intel.com> <56407297.2060309@frisch.fr> <564076EA.7020805@mpi-sws.org> <5640D8E0.6060102@lexifi.com> Cc: Andreas Rossberg , caml users From: Alain Frisch Message-ID: <564102E1.3060004@lexifi.com> Date: Mon, 9 Nov 2015 21:32:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-DRWEB-SCAN: ok X-VRSPAM-SCORE: -51 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrfeekhedrfeelgdehkecutefuodetggdotefrucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpjgetkgfkueetnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenucfjughrpefuvfhfhffkffgfgggjtgfgsehtjegrtddtfeejnecuhfhrohhmpeetlhgrihhnucfhrhhishgthhcuoegrlhgrihhnrdhfrhhishgthheslhgvgihifhhirdgtohhmqeenucffohhmrghinhepihhnrhhirgdrfhhrpdhgihhthhhusgdrtghomhdphigrhhhoohdrtghomhenucfrrghrrghmpehmohguvgepshhmthhpohhuth X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht Subject: Re: [Caml-list] Newbie comment on constructor syntax On 09/11/2015 19:08, Gabriel Scherer wrote: > If we gave a functional semantic to the unapplied constructor, then I > think that good taste would mandate for the application of this > function and the application of the constructor to be equivalent. This > means that by choosing a tuple-taking function, we commit to the > tuple-application syntax (that nobody likes), and that choosing a > currified function creates an unpleasant inconsistency in the > language. > > I don't know whether we could ever manage to transition to a currified > syntax for constructors, but right now it is at least conceivable > because the application syntax is just a concrete syntax choice, it > does not affect typing. Turning unapplied constructor into a function > (tuplified or currified) makes it a typing property, observable at > specification boundaries: we cannot change it. Making it easier to switch in the distant future to currified constructors does not seem a strong argument against improving the language now (especially reducing bad surprises for beginners). The tuple-like syntax is not very much liked, but this is partly caused by the fact that arguments cannot be manipulated as real tuples. With the proposed change, this argument goes away. Moreover, *if* we ever wanted to switch to currified constructors, this would not be a purely syntactic rewriting anyway, even with the current language. One would need to have access to constructor declarations to drive the rewriting process. If you one allows oneself to get such information out of the type checker, doing the rewriting even in presence of the currently suggested changes would be possible as well (with extra wrapping/unwrapping). Alain > > On Mon, Nov 9, 2015 at 6:33 PM, Alain Frisch wrote: >> On 09/11/2015 11:35, Andreas Rossberg wrote: >>> >>> Yes please, I would appreciate such sugar. >> >> >> I've now submitted a cleaner implementation, working on both expressions and >> patterns: >> >> https://github.com/ocaml/ocaml/pull/284 >> >>> Even more I would appreciate >>> generalising that to allowing constructors to be used as first-class >>> expressions (i.e., unapplied "C" -> "fun (x1,...,xN) -> C (x1,...,xN)" >>> when C is a constructor with arity > 0). I had to write some AST mapping >>> code recently that would have vastly benefited from that. >> >> >> This is not covered (and now, it could simply be "fun x -> C x" :-)). I >> don't see anything clever to be done on patterns for "unapplied >> constructors", though. >> >> >> Alain >> >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs