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 21C3F7F7AF for ; Sat, 10 Oct 2015 19:32:56 +0200 (CEST) IronPort-PHdr: 9a23:LmsNOB/z8DMkqP9uRHKM819IXTAuvvDOBiVQ1KB91OocTK2v8tzYMVDF4r011RmSDdmdtKMP0rOI+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuStKU0JX8jrnss7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cY6Lod8JtsWKP7cqAPZyheHjAnezQ57cvquB2FRxaC4GkYU00biABBHwnc8Ry8VZen4QXgse8okhGXIdH7V/gdH3yf9aRmRBbswm9TLzck6mLahsV0pK1eqROl4Rd4xtiHM8muKPNic/aFLpshTm1bU5MJWg== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=paurkedal@gmail.com; spf=Pass smtp.mailfrom=paurkedal@gmail.com; spf=None smtp.helo=postmaster@mail-ob0-f176.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of paurkedal@gmail.com) identity=pra; client-ip=209.85.214.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="paurkedal@gmail.com"; x-sender="paurkedal@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of paurkedal@gmail.com designates 209.85.214.176 as permitted sender) identity=mailfrom; client-ip=209.85.214.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="paurkedal@gmail.com"; x-sender="paurkedal@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ob0-f176.google.com) identity=helo; client-ip=209.85.214.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="paurkedal@gmail.com"; x-sender="postmaster@mail-ob0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AwBwBWSxlWm7DWVdFegz4HNW4GsVqNciGCcoIKfwKBGQc8EAEBAQEBAQEBEAEBAQEBBgsLCSEugh+CCAEBAgEBEhEEGQEbEgsBAwELBgULDwImAgIiAREBBQEcBhMIGod2AQMKCA2he4ExPjGLSYFsgnmJDgoZJw1WhEsBAQEHAgEZAQUOgRSFUoN3gQaEWjMHgmmBRQWHRIZ6h1UBhRiCcIURgViHXo5egiMSI4EXOIIvI4FdPDMBh2kBAQE X-IPAS-Result: A0AwBwBWSxlWm7DWVdFegz4HNW4GsVqNciGCcoIKfwKBGQc8EAEBAQEBAQEBEAEBAQEBBgsLCSEugh+CCAEBAgEBEhEEGQEbEgsBAwELBgULDwImAgIiAREBBQEcBhMIGod2AQMKCA2he4ExPjGLSYFsgnmJDgoZJw1WhEsBAQEHAgEZAQUOgRSFUoN3gQaEWjMHgmmBRQWHRIZ6h1UBhRiCcIURgViHXo5egiMSI4EXOIIvI4FdPDMBh2kBAQE X-IronPort-AV: E=Sophos;i="5.17,664,1437429600"; d="scan'208";a="182104102" Received: from mail-ob0-f176.google.com ([209.85.214.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 10 Oct 2015 19:32:55 +0200 Received: by obbbh8 with SMTP id bh8so83453116obb.0 for ; Sat, 10 Oct 2015 10:32:54 -0700 (PDT) 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:content-transfer-encoding; bh=7ufeHaBTR6JbsWHnwciWVeR2lOs48HXhb2zg/fvMn20=; b=enZ8sUBBueloAxMOIWVWMyLvQv4rBb7bQ/0SoeXMwawWFewGdJf1ebz+B5rJlfgk+Q A0QgoDV5yPayyFsy+nergiO4ZrcS/l95ud2gj1Ccb97QuWKdkFuo/RMQ3+dBzgE7qEcy nSlJcBaoZPFewGMXHtzHSUoBheIXHl1ip5YibYfucpWqyplkewGbZK3nAjrmMEt6xGw4 y+Jb4M45FqmXUALgUb5MKU4wMfekUJGleN9uoTdmOKHJDS9YeoqvW+0Y6Lb+ijc0qbmL 6xIwkaKs0iZlN57K80b6u3dwfhGFeNqRjbzsIJvZnVB2gx0wCl9uDVS4B58GQn2BZxxB ULAg== MIME-Version: 1.0 X-Received: by 10.60.220.227 with SMTP id pz3mr11270978oec.13.1444498373955; Sat, 10 Oct 2015 10:32:53 -0700 (PDT) Received: by 10.202.92.136 with HTTP; Sat, 10 Oct 2015 10:32:53 -0700 (PDT) In-Reply-To: References: Date: Sat, 10 Oct 2015 19:32:53 +0200 Message-ID: From: "Petter A. Urkedal" To: =?UTF-8?Q?Daniel_B=C3=BCnzli?= Cc: caml users Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Terser ppx syntax for common usage (like monads) I forgot to CC the list when replying, so sending a digest in cronological order. (Including Daniel B=C3=BCnzli's responses, cited in good faith.) =3D=3D=3D=3D 2015-10-10 16:09 GMT+02:00 Daniel B=C3=BCnzli : >> Now, that's not necessarily a bad thing, but the monad bind operation >> tends to be quite invasive, so I'd like to suggest adding a shorter >> syntax which the user could choose to map to their most pervasive ppx >> rewriter. > > This entails that I can't possibly have an idea of what the code is doing= without looking up what the build system is doing which is annoying. We sh= ould aim for self-describing sources rather than put too much knowledge in = the build systems =E2=80=94 which also means that usage of pre-processors s= hould be frown upon in general. The added opaqueness could be avoided by aliasing kw* to kw%ext for some ext in the source code. This would also allow delimiting the scope. Though, you raise a more general issue. Do you have an alternative? Should people stick with [... >>=3D fun x -> ...], or should monad support be added to the compiler? What about deriving extensions? =3D=3D=3D=3D Le samedi, 10 octobre 2015 =C3=A0 16:20, Petter A. Urkedal a =C3=A9crit : > Though, you raise a more general issue. Do you have an alternative? Not really. > Should people stick with [... >>=3D fun x -> ...], That's personally what I do for now. I don't like pre-processors since they do not compose in general and needlessly complicate and opacify build systems and your code. They do solve real problems, but in the wrong way. I hope that in a few years we will have something along this line [1]. Meanwhile I'm willing to stay away as much as possible from pre-processors=E2=80=A6 > or should monad support be added to the compiler? There was some discussion about this at some point to add some magic for this on `let` keywords, I don't remember the details but it was rejected =E2=80=94 was kind of an ad-hoc hack to be honest. I wanted to poi= nt you to this but the perspective of having to search the mailing list archive put me off, I'll let you do that=E2=80=A6 Best, Daniel [1] http://www.lpw25.net/ocaml2015-abs1.pdf =3D=3D=3D=3D 2015-10-10 17:28 GMT+02:00 Daniel B=C3=BCnzli : > Le samedi, 10 octobre 2015 =C3=A0 16:20, Petter A. Urkedal a =C3=A9crit : >> Should people stick with [... >>=3D fun x -> ...], > > That's personally what I do for now. I don't like pre-processors since th= ey do not compose in general and needlessly complicate and opacify build sy= stems and your code. They do solve real problems, but in the wrong way. I h= ope that in a few years we will have something along this line [1]. Meanwhi= le I'm willing to stay away as much as possible from pre-processors=E2=80=A6 Yes, a macro system would be better. I was a bit surprised to see it's typed, considering the issues of representing typed lambda calculus within it self [2]. I haven't read that close enough to tell whether it applies here though. (The original James Chapman may be an easier read.) Your [1] reference is talking about performance, and if one is willing to give up on that, a canonical rewrite might suffice for common extensions dealing with control flow: let%ext x =3D y in z --> let_ext y (fun x -> z) if%ext x then y else z --> if_ext x (fun () -> y) (fun () -> z) while%ext x do y done --> while_ext x (fun () -> y) etc. So, concurrency seems to be non-essential use of syntax extension, as opposed to deriving and other type-driven extensions. >> or should monad support be added to the compiler? > > There was some discussion about this at some point to add some magic for = this on `let` keywords, I don't remember the details but it was rejected = =E2=80=94 was kind of an ad-hoc hack to be honest. I wanted to point you to= this but the perspective of having to search the mailing list archive put = me off, I'll let you do that=E2=80=A6 Didn't find that, but in any case, it does not sound like a good idea to let the same construct handle both cases without somehow tagging the usage as monadic, if that was the magic involved. In any case, I think it is good to have a system which decouples the development of new features from the development of OCaml itself, and to avoid accreting esoteric features. [1] http://www.lpw25.net/ocaml2015-abs1.pdf [2] http://homotopytypetheory.org/2014/03/03/hott-should-eat-itself/