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 6BA377EEFA for ; Mon, 9 Nov 2015 23:27:15 +0100 (CET) IronPort-PHdr: 9a23:pn5uoxJ2QAg44k4qrNmcpTZWNBhigK39O0sv0rFitYgVKvXxwZ3uMQTl6Ol3ixeRBMOAu68C17Gd6v2wEUU7or+/81k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZvIaytQ8iJ35nxi7v5osCDKyxzxxODIppKZC2sqgvQssREyaBDEY0WjiXzn31TZu5NznlpL1/A1zz158O34YIxu38I46Fp34d6XK77Z6U1S6BDRHRjajhtpZ7djgTYVQaE+lcbV2wXlFIIX1mEv1nGWcLeuyHgt+d5kBKRPcDsQKp8DTur5b1qRRuukywHOiQ06knYj8VxiORQpxf39DJlxIuBSYeZLvd3ZevnesgBT2dbUY4FTStaGYmxdYQnCvIAeP1HtM/6vVRY/kj2PhWlGO66kmwAvXTxx6Bvlrl4HA== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=rossberg@mpi-sws.org; spf=Pass smtp.mailfrom=rossberg@mpi-sws.org; spf=None smtp.helo=postmaster@hera.mpi-klsb.mpg.de Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of rossberg@mpi-sws.org) identity=pra; client-ip=139.19.1.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="rossberg@mpi-sws.org"; x-sender="rossberg@mpi-sws.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of rossberg@mpi-sws.org designates 139.19.1.49 as permitted sender) identity=mailfrom; client-ip=139.19.1.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="rossberg@mpi-sws.org"; x-sender="rossberg@mpi-sws.org"; 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@hera.mpi-klsb.mpg.de) identity=helo; client-ip=139.19.1.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="rossberg@mpi-sws.org"; x-sender="postmaster@hera.mpi-klsb.mpg.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D0AQDaHEFWhDEBE4tehA4sAUKucI9dgWMXCoIug0ECgT85EwEBAQEBAQEBEAEBAQoHBAkJIS6CLoIHAQEBAwEjBBkBASwLAQQLCxgCAgkdAgIhJBIGExIHiAADCggECbARcYRjAQWHJgMKhEkBAQEBAQEBAQEBAQEBAQEBAQEBAQESBoEBh2OCboJTggaCYjoTHIEVhhAMkDGFHoYUg1BJg3eCfotZg2GDciMBgkMjgV5xhWYBAQE X-IPAS-Result: A0D0AQDaHEFWhDEBE4tehA4sAUKucI9dgWMXCoIug0ECgT85EwEBAQEBAQEBEAEBAQoHBAkJIS6CLoIHAQEBAwEjBBkBASwLAQQLCxgCAgkdAgIhJBIGExIHiAADCggECbARcYRjAQWHJgMKhEkBAQEBAQEBAQEBAQEBAQEBAQEBAQESBoEBh2OCboJTggaCYjoTHIEVhhAMkDGFHoYUg1BJg3eCfotZg2GDciMBgkMjgV5xhWYBAQE X-IronPort-AV: E=Sophos;i="5.20,267,1444687200"; d="scan'208";a="153280900" Received: from hera.mpi-klsb.mpg.de ([139.19.1.49]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 09 Nov 2015 23:27:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mpi-sws.org; s=mail200803; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Content-Type:Mime-Version:Subject; bh=5xtmqlsaWaRIkQVoYatp+ba36mU5Gagel49Tm4E083I=; b=FiSGl/n7JdQYIWoE+6qJGfDlm0wZfocppO0SuTRd5qeiJRCP7NIC1dPC28WQJPSGBQ/RCR9QGlUSi82nSPzW2ek1vLGWzKDgpudzCux7ZTNrL51IKW8ZWxEqUnYluxR8GpLLnmy+yowzJSboceVHrBqTGBR28QJIAvsndnLONhI=; Received: from srv-00-125.mpi-klsb.mpg.de ([139.19.1.28]:34648 helo=maniac.mpi-klsb.mpg.de) by hera.mpi-klsb.mpg.de (envelope-from ) with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) id 1Zvuu6-0002lO-LW; Mon, 09 Nov 2015 23:27:12 +0100 Received: from 109.125.107.239.dynamic.cablesurf.de ([109.125.107.239]:54424 helo=macbook-air.fritz.box) by maniac.mpi-klsb.mpg.de (envelope-from ) with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) id 1Zvuu6-0007iH-0N; Mon, 09 Nov 2015 23:27:10 +0100 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: Andreas Rossberg In-Reply-To: Date: Mon, 9 Nov 2015 23:27:08 +0100 Cc: Alain Frisch , caml users Content-Transfer-Encoding: quoted-printable Message-Id: <95AE93FB-4D5A-43E2-B72F-40C348403AA6@mpi-sws.org> 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> <5640E2EF.7070400@mpi-sws.org> To: Gabriel Scherer X-Mailer: Apple Mail (2.2104) X-MPI-Local-Sender: true Subject: Re: [Caml-list] Newbie comment on constructor syntax > On Nov 9, 2015, at 22:11 , Gabriel Scherer wr= ote: >=20 > On Mon, Nov 9, 2015 at 7:16 PM, Andreas Rossberg w= rote: >> Hm, I see your point, but don't you already introduce that problem (i.e., >> commit to tuples) by allowing the `C x` sugar for n-ary constructors? >> Because in a world of curried constructors, `x` would not be typed as the >> tuple of arguments, but only as the first argument of the constructor. >=20 > Yes, it is already problematic, and in fact I'm personally not > completely convinced by this feature -- Alain it "reduces bad > surprises for beginners", but I suspect that adding more magic in this > place could not actually help that much -- at least the current > semantic model is simple. >=20 > Another problem with (C x) is the non-trivial performance implications of > | C x -> x > which actually allocates. That is already the case for some other patterns, e.g. matching float-only = records, isn=E2=80=99t it? > The problem would only get worse if we allowed > type t =3D { mutable x : int; mutable y : int } > type u =3D Packed of { mutable x : int; mutable y : int } > let pack x =3D Packed x > with an observable change in mutability semantics from the same code with > type u =3D Packed of t > (but Alain has not suggested adding this feature to decrease surprises > (yet?), and luckily our tuples are immutable.) I haven=E2=80=99t yet used the new records in datatypes feature, but I assu= me the above would involve to distinct nominal types, so there is no reason= to assume them compatible. > I like the revised syntax choice of writing > type t =3D A of int and int list > instead of > type t =3D A of int * int list > which removes the beginner surprise without introducing other > unpalatable design side-effects. (It is still awkward for GADTs, but > such is life.) I am not fond of the revised syntax, because it does not explain why the te= rm-level syntax for constructor application uses tuple notation. It seems to me that tuples are already engrained in the current syntax and = semantics. I doubt it will ever be realistically possible to change their m= eaning. If you want currying, then the backwards-compatible way would be in= troducing curried constructors as a new form, in addition to tupled ones. T= hey would have a different type, and nothing would be particularly wrong wi= th that! I would sign a petition for such an extension immediately. :) /Andreas > Sometime I think it's wise to avoid local improvements that get stuck > in local maxima. >=20 > (This is also my argument against Haskell's choice of using the same > syntax for the pairs (x, y) and the types of pairs (t, u). I guess at > the time they thought that, of course, they would never get type-level > pairs.) >=20 > On Mon, Nov 9, 2015 at 7:16 PM, Andreas Rossberg w= rote: >> On 11/09/2015 07:08 PM, Gabriel Scherer wrote: >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >>=20 >> Hm, I see your point, but don't you already introduce that problem (i.e., >> commit to tuples) by allowing the `C x` sugar for n-ary constructors? >> Because in a world of curried constructors, `x` would not be typed as the >> tuple of arguments, but only as the first argument of the constructor. >>=20 >> /Andreas >>=20 >>=20 >>=20 >>> On Mon, Nov 9, 2015 at 6:33 PM, Alain Frisch >>> wrote: >>>>=20 >>>> On 09/11/2015 11:35, Andreas Rossberg wrote: >>>>>=20 >>>>>=20 >>>>> Yes please, I would appreciate such sugar. >>>>=20 >>>>=20 >>>>=20 >>>> I've now submitted a cleaner implementation, working on both expressio= ns >>>> and >>>> patterns: >>>>=20 >>>> https://github.com/ocaml/ocaml/pull/284 >>>>=20 >>>>> 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 mapp= ing >>>>> code recently that would have vastly benefited from that. >>>>=20 >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>> Alain >>>>=20 >>>>=20 >>>> -- >>>> 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 >>=20 >>=20 >=20 > --=20 > 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