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 3AD0482355 for ; Mon, 11 Dec 2017 15:40:35 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=info@gerd-stolpmann.de; spf=None smtp.mailfrom=info@gerd-stolpmann.de; spf=None smtp.helo=postmaster@mout.kundenserver.de Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.126.133; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.126.133; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.kundenserver.de) identity=helo; client-ip=212.227.126.133; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@mout.kundenserver.de"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3A8WBWaRAaNx7stPK5NGy7UyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSP3zpMbcNUDSrc9gkEXOFd2Crakb26yL6+jJYi8p39WoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6lCs4CQtGhTjOE8w?= =?us-ascii?q?D6y1X9eK14Xkn9y1rpbaZgENgDumfZtzKg+3pEPfrJo4m4xnf4k80BeBmWdPf/?= =?us-ascii?q?xTzGVubQaSmRj7zsi95pIm6DhXv+ok/shGF6n3KfdrBYdEBSgrZjhmrPbgsgPO?= =?us-ascii?q?GE7WviMR?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAQAJmC5ah4V+49RbHAEBAQQBAQoBA?= =?us-ascii?q?YQkdCeEAosfjX6BTi8QmREHAx+FHAKEckMUAQEBAQEBAQEBARIBAQEIDQkIKC+?= =?us-ascii?q?COCQBgkYBAgMjBC40CQIYKgICVxMGAgEBBQuKGAELihydbIFtOopjAQEIAgEWD?= =?us-ascii?q?4NoggtUgxSDAoMjgghAgkmCYwWKRhyYL4EQcgOCR4IrmjaHV5ZegTs2SIEpTCQ?= =?us-ascii?q?UOoIpCYJZgXR3AYleAQEB?= X-IPAS-Result: =?us-ascii?q?A0CCAQAJmC5ah4V+49RbHAEBAQQBAQoBAYQkdCeEAosfjX6?= =?us-ascii?q?BTi8QmREHAx+FHAKEckMUAQEBAQEBAQEBARIBAQEIDQkIKC+COCQBgkYBAgMjB?= =?us-ascii?q?C40CQIYKgICVxMGAgEBBQuKGAELihydbIFtOopjAQEIAgEWD4NoggtUgxSDAoM?= =?us-ascii?q?jgghAgkmCYwWKRhyYL4EQcgOCR4IrmjaHV5ZegTs2SIEpTCQUOoIpCYJZgXR3A?= =?us-ascii?q?YleAQEB?= X-IronPort-AV: E=Sophos;i="5.45,391,1508796000"; d="asc'?scan'208";a="304941809" Received: from mout.kundenserver.de ([212.227.126.133]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-GCM-SHA256; 11 Dec 2017 15:40:34 +0100 Received: from office1.lan.sumadev.de ([85.183.69.161]) by mrelayeu.kundenserver.de (mreue005 [212.227.15.167]) with ESMTPSA (Nemesis) id 0MGDrv-1eIel41gAh-00FEwX for ; Mon, 11 Dec 2017 15:40:33 +0100 Received: from gerdbook.fritz.box (gerdbook.fritz.box [192.168.5.104]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id DE305DC05D for ; Mon, 11 Dec 2017 15:40:32 +0100 (CET) To: caml-list@inria.fr References: From: Gerd Stolpmann Message-ID: <6640cb32-fec3-e048-3f40-53d65bae5305@gerd-stolpmann.de> Date: Mon, 11 Dec 2017 15:40:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Lp3IPla4ERNfutPWAKSEuRMJE2uPjK2j3" X-Provags-ID: V03:K0:vXbvWS/1/BgqJpJJatf6UPHdO9oN0fpDOZ5rx7jUqjatW39pc+1 FgfpX+NVjFsVXK7o9vKK9WHF8pGUqQsm0GpvVJnptdc68OXNawBpSajV9CXVmGRZrdXct5g Pg7Z5rimZzkf0EqdoGcCviLBY3jzS3EdSgXCBwbiVxgNCgrcpppAwC6X9rx83Uz7ZvDqqZ1 8kZEuClcGx/IxKhSdm8LA== X-UI-Out-Filterresults: notjunk:1;V01:K0:pRrDdzb4gc4=:O4cTkdsqjLzmwhfoLLqmy/ Y7dIEXHJDJvgwRFl50Zr98njFPK3hMQNcrUPBY9eBLKco6Yt9HtyOGp3oACSL/kkgunwcY3Ye sKfgRhh6eh5BRhkiiJDM41ZnN5GBcofD9aiW+XIua7MRwLsKlq6WHiuTLLAJoSAe0g7JRyffn DEeDWt6mg1GS6QLKQ+MzNxnQMLpZUtzXs2YZM/OWuTHNuj3f1w72EoFCkVFqgRuvr3Y8I1Dp9 qp0u5Y83t6H1XydIxaZSQmlmTFS6jiEYbnrJvKKspVwxVvARlvewcPHaBvyJKRKUCNjTbFne0 eA63IVeQ0h1OqtUnTNYeCkt7RDdvXDwaHj3A+TMHpg8jL3I+2oeZnRODaKN27iCvn8hgINOhR tv4F5q2jVU6a54MHnkpHbKItzwDcbeqQliycvFfNTMBdAU8BRLWiERYrrn3PXLkihcMXOFqw7 J7Z3drrntErvA4LgSr5Gpk8tTjxqArzi5v8x9/XLj7OtYaDfsEqXDqxctISyca+nV9b+sOUg9 RSi0lbf2iBgFOFCW4jW372kquAqukLD4Ny9M5jkDhkn87P1jTnPuaMUT3IJAgnvGtIgQnEEfL CJOGc+gV0k0dFgHqBu+nvAXbB/mSUbLoA0T8tHgC+cfBU9YfdszPIety9pSSWgHWHyl9t16Yt b8u66eD1H5oAXvyNLdJFu7bf6+L4+PPLAAFOZ7L4Sbe+3BzYXuz1hhIBkUadvnXLzP61VTVQh TbXobDLB4RQPdxdEAWzASPMFmpLTuLlNoN8oMw== Subject: Re: [Caml-list] ReasonML concrete syntax This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Lp3IPla4ERNfutPWAKSEuRMJE2uPjK2j3 Content-Type: multipart/mixed; boundary="rtBiCLlWK5mLsEBBJjltm8tc8nuKFg9Qo"; protected-headers="v1" From: Gerd Stolpmann To: caml-list@inria.fr Message-ID: <6640cb32-fec3-e048-3f40-53d65bae5305@gerd-stolpmann.de> Subject: Re: [Caml-list] ReasonML concrete syntax References: In-Reply-To: --rtBiCLlWK5mLsEBBJjltm8tc8nuKFg9Qo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi, funnily I made similar decision in the programming language I'm currently developing (because of the commercial background it's closed source so far, so no pointer). The reasoning is simply that "normal" people are so used to writing functions with the parenthesized notation that they do not even recognize functions without. For tuples, there is a separate notation with square brackets in my language, so no conflict (you can still write tuplified functions). Another reason is that notations that do not have a clear syntactical end mark are more difficult to understand (although, with currified functions this is only an illusion). In short, the argument is that f(x1,g(x2,x3)) looks more familiar than f x1 (g x2 x3). Personally I dislike that, but I'm not normal, and my language is not designed for myself. Gerd On 10.12.17 19:12, Robert Muller wrote: > The team developing ReasonML seems to be experimenting with concrete > syntax in an effort to make it feel as familiar and natural as > possible to JavaScript programmers. Seems like a good idea. But the > present version seems to hardwire parentheses awkwardly for function > definitions and calls. Parentheses are required for both function > definitions and calls. So one writes > > let incr(n) =3D n + 1=C2=A0 =C2=A0 =C2=A0 =C2=A0and=C2=A0 =C2=A0incr(5) > > but not > > let incr n =3D n + 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 or=C2=A0 =C2=A0 incr 5 > > Fair enough, but for multi-argument functions the parser seems to > unroll the parenthesized items (both parameters & arguments) to leave > curried functions. E.g., > > let add(m, n) =3D m + n=C2=A0 or equivalently let add =3D (m, n) =3D> m += n > > then add(5, 3) is 8 as one would expect. But the (m, n) in let add(m, > n) =3D ... isn't a pattern matching a pair, it's the JS-style sequence > of input parameters and the definition unrolls to let add =3D (m) =3D> (n) > =3D> ... . So add(5) : int -> int and all three of add(5, 3), add(5)(3) > and { let add5 =3D add(5);=C2=A0 add5(3) } are 8. There's probably a way = to > write an add function of type int * int -> int, but I don't know how > to write it. > > I'm wondering what the OCaml community makes of this. I find it awkward. > Bob Muller > > --=20 ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de My OCaml site: http://www.camlcity.org Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------ --rtBiCLlWK5mLsEBBJjltm8tc8nuKFg9Qo-- --Lp3IPla4ERNfutPWAKSEuRMJE2uPjK2j3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEDD3jJ6xcCmoYHoi4Bozhv1ksHlMFAloumNoACgkQBozhv1ks HlMAdQf7Bla43BTZ5gYH639aVQ9bNZ1Gq5Zax16ketCr4fLEozk3S8r+q8fF3LG9 M8O2eCJnVKzIQLgJmH/FProfhM1hbLzFWsODq3rQC21QsC9E2RG6Qh+fLPze9N3Q 4/q1nqj+lt9C9kwMekazNMapjJBwVP/b5VnB+JR0z+yenaUImx6I7hPumXIx3L4R Y8hCoO6vfXRNSyj6XnncXDBJV91ZW5mpDFfNB9YbNRDOFY4s8ORzm/Z633v54D5D 2xVK2qD5RKcTLkqeN0beOBL9xhJdejIuFboNTOvI8ECUIFpGa8m+tPdih4Ca9qKu n0NYI7wx3n2CEyrADpxQKR3hD8aD+A== =ll1r -----END PGP SIGNATURE----- --Lp3IPla4ERNfutPWAKSEuRMJE2uPjK2j3--