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 6FD6C7F6D8 for ; Tue, 20 Jan 2015 04:53:54 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jun.furuse@gmail.com) identity=pra; client-ip=74.125.82.52; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jun.furuse@gmail.com"; x-sender="jun.furuse@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of jun.furuse@gmail.com designates 74.125.82.52 as permitted sender) identity=mailfrom; client-ip=74.125.82.52; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jun.furuse@gmail.com"; x-sender="jun.furuse@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-wg0-f52.google.com) identity=helo; client-ip=74.125.82.52; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jun.furuse@gmail.com"; x-sender="postmaster@mail-wg0-f52.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikBAKzQvVRKfVI0m2dsb2JhbABchDAEzDQCgRoHQwEBAQEBEQEBAQEBBgsLCRQuhA0BAQMBDAYuARsQCgMBAwwGBQs7IgERAQUBHAYTIod1AQMBBAQIrVM+MY0ZgneKSgoZJw0YPINIAQEBAQEFAQEBAQEBARUBBQ6KAYUSWAeEKQWJdI18gRSFPINKhkYSI4EVhB0xMYEDgUABAQE X-IPAS-Result: AikBAKzQvVRKfVI0m2dsb2JhbABchDAEzDQCgRoHQwEBAQEBEQEBAQEBBgsLCRQuhA0BAQMBDAYuARsQCgMBAwwGBQs7IgERAQUBHAYTIod1AQMBBAQIrVM+MY0ZgneKSgoZJw0YPINIAQEBAQEFAQEBAQEBARUBBQ6KAYUSWAeEKQWJdI18gRSFPINKhkYSI4EVhB0xMYEDgUABAQE X-IronPort-AV: E=Sophos;i="5.09,431,1418079600"; d="scan'208";a="117719028" Received: from mail-wg0-f52.google.com ([74.125.82.52]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 20 Jan 2015 04:53:53 +0100 Received: by mail-wg0-f52.google.com with SMTP id l2so12864816wgh.11 for ; Mon, 19 Jan 2015 19:53:52 -0800 (PST) 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; bh=6YuOZTk8vRvKkK/NU8aec2WIEdQf7JGLrAs4CZY0WcQ=; b=gOriJuoRfT4fcfs32+/xDvpnR917hLP8UJQ5lR0atrnefHwH6UAC251sJh7DUtPMBN RP4ijINMl3uisj/IsWy5xdv4jV9d2QLTVNw0dmE14tWnlkoWVs2uwMV05O1PO2cCJLam mAYKkHY9g70RodyWSGYPJnlmEmWW7RkIvuQWgI5XogfeoecI/jmOIWsfMrR7MVeZsozA CFXz3hGt8CKZCo/4Oq6SQVgFT1QaCmAeqKg8SiDjd0mZgC8212Dnq5NndS4QBzvpYSog TYE1xkbp68Z6PP3JbvMfGBtMqWWy0u+0sBAh/uPnXQHw+u7mQclNfAWWUwtlHZ9TeQNc 61MQ== MIME-Version: 1.0 X-Received: by 10.194.179.68 with SMTP id de4mr35597775wjc.42.1421726032906; Mon, 19 Jan 2015 19:53:52 -0800 (PST) Received: by 10.194.100.130 with HTTP; Mon, 19 Jan 2015 19:53:52 -0800 (PST) Received: by 10.194.100.130 with HTTP; Mon, 19 Jan 2015 19:53:52 -0800 (PST) In-Reply-To: <54BD7CBB.50409@zoho.com> References: <20150114084056.140F6C38A1@www1.g3.pair.com> <54BCC6D6.6020702@frisch.fr> <54BD7CBB.50409@zoho.com> Date: Tue, 20 Jan 2015 11:53:52 +0800 Message-ID: From: Jun Furuse To: Drup Cc: caml-list , Alain Frisch , oleg@okmij.org Content-Type: multipart/alternative; boundary=089e01493cb028d09d050d0d632a Subject: Re: [Caml-list] [ANN] ppx_monadic.1.0.2, ppx for monadic do, pattern --089e01493cb028d09d050d0d632a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I know what you wrote, since I always asked myself "isn't it too bizarre?" when I was writing ppx_monadic. Here are some justifications I made: The first intension of ppx_monadic is to port my code with pa_monad without pain. Unfortunately ppx_monad required too many small fixes due to the following reasons: =B7 "perform" needed to be replaced by "begin%monad .. end" or "[%mon= ad .. ]" which requires closing, which is really pain. Ppx_monad provides "fun%monad", "match%monad" without closing but they were not always helpful for me. =B7 The pattern "p" of "p <- e" is limited to a variable, since it overrides the syntax of object member mutation. In addition, I use lots of monadic binds inside my class methods. Therefore this override is not acceptable for me. Secondary, I see the monadic syntax sugar is to reduce the number of key types, and I accepted some alien syntax weirdness for the purpose. If the number of key types would not matter, I would be happy with the good old bind (>>=3D) chains and would not use "do" at all. People think bind chains are hard to read but my experience with Jane Street Async tells me it it not quite. Ppx_monad does not really gain in this point unfortunately: I was often forced to write "let%monad (x,y) =3D e in" just for "(x,y) <-- e;= ". I write Haskell do-notations daily and wanted to have something comparable in OCaml. Anyway, the current OCaml syntax is limited to have do-notation which makes everyone happy. If there would be a way in OCaml to write "foo e" for some keyword "foo" which is like "begin" but does not require "end", I would be pretty happy to change the weird "Option.do_; e" to "foo%Option e". Before implementing "do_; e", I tried a bit of "[%do] e" but it did not work well since "[%do] p <-- e" is parsed as "([%do] p) <-- e", not "[%do] (p <-- e)". Best, Jun On 20 Jan, 2015 5:53 am, "Drup" wrote: > > I can appreciate that authors of tools that requires special syntactic >> support would love to have their new forms look completely native to use= rs, >> but the counter-argument can be made that keeping an explicit syntax >> (through the '%' character) for features that are not part of the offici= al >> language is a good property. (Camlp4/campl5 are still available for peop= le >> who want to play with the concrete syntax.) >> > > I personally like the explicitness of the syntax a lot. The only issue in > OCaml currently is that, given the need for retro compatibility, it goes > sometimes against the terseness. For example the impossibility to do " x@= foo" > instead of "x[@foo]". That's unavoidable, though. > > This is, by the way, a point I dislike a lot with ppx_monadic. It abuses > the native syntax in completely alien ways and without annotations. > > I like ppx_monad's syntax quite better due to the fact that it's always > explicitly a ppx (thanks to %monad) and do not overload the "do_" > identifier. > > --089e01493cb028d09d050d0d632a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I know what you wrote, since I always asked myself “is= n’t it too bizarre?” when I was writing ppx_monadic. Here are s= ome justifications I made:

The first intension of ppx_monadic is to port my code with p= a_monad without pain. Unfortunately ppx_monad required too many small fixes= due to the following reasons:

=B7       “perform&= rdquo; needed to be replaced by “begin%monad .. end” or “= [%monad .. ]” which requires closing, which is really pain. Ppx_monad= provides “fun%monad”, “match%monad” without closin= g but they were not always helpful for me.
=B7       The pattern “p” of= “p <- e” is limited to a variable, since it overrides the s= yntax of object member mutation. In addition, I use lots of monadic binds i= nside my class methods. Therefore this override is not acceptable for me.

Secondary, I see the monadic syntax sugar is to reduce the n= umber of key types, and I accepted some alien syntax weirdness for the purp= ose. If the number of key types would not matter, I would be happy with the= good old bind (>>=3D) chains and would not use “do” at a= ll. People think bind chains are hard to read but my experience with Jane S= treet Async tells me it it not quite. Ppx_monad does not really gain in thi= s point unfortunately: I was often forced to write “let%monad (x,y) = =3D e in” just for “(x,y) <-- e;”. I write Haskell do-= notations daily and wanted to have something comparable in OCaml.

Anyway, the current OCaml syntax is limited to have do-notat= ion which makes everyone happy. If there would be a way in OCaml to write &= ldquo;foo e” for some keyword “foo” which is like “= begin” but does not require “end”, I would be pretty happ= y to change the weird “Option.do_; e” to “foo%Option e&rd= quo;. Before implementing “do_; e”, I tried a bit of “[%d= o] e” but it did not work well since “[%do] p <-- e” i= s parsed as “([%do] p) <-- e”, not “[%do] (p <-- e)= ”.

Best,
Jun

On 20 Jan, 2015 5:53 am, "Drup" <drupyog+caml@zoho.com> wrot= e:

I can appreciate that authors of tools that requires special syntactic supp= ort would love to have their new forms look completely native to users, but= the counter-argument can be made that keeping an explicit syntax (through = the '%' character) for features that are not part of the official l= anguage is a good property. (Camlp4/campl5 are still available for people w= ho want to play with the concrete syntax.)

I personally like the explicitness of the syntax a lot. The only issue in O= Caml currently is that, given the need for retro compatibility, it goes som= etimes against the terseness. For example the impossibility to do " x@= foo" instead of "x[@foo]". That's unavoidable, though.
This is, by the way, a point I dislike a lot with ppx_monadic. It abuses th= e native syntax in completely alien ways and without annotations.

I like ppx_monad's syntax quite better due to the fact that it's al= ways explicitly a ppx (thanks to %monad) and do not overload the "do_&= quot; identifier.

--089e01493cb028d09d050d0d632a--