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 3A1727FA5E for ; Fri, 21 Apr 2017 23:18:08 +0200 (CEST) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=Fabrice.Le_fessant@inria.fr; spf=Pass smtp.mailfrom=fabrissimo@gmail.com; spf=None smtp.helo=postmaster@mail-qt0-f179.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of Fabrice.Le_fessant@inria.fr) identity=pra; client-ip=209.85.216.179; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="Fabrice.Le_fessant@inria.fr"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of fabrissimo@gmail.com designates 209.85.216.179 as permitted sender) identity=mailfrom; client-ip=209.85.216.179; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="fabrissimo@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-qt0-f179.google.com) identity=helo; client-ip=209.85.216.179; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="postmaster@mail-qt0-f179.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AGCvlRh+ZbX/GP/9uRHKM819IXTAuvvDOBiVQ1KB2?= =?us-ascii?q?0uMcTK2v8tzYMVDF4r011RmSDNmds6oMotGVmpioYXYH75eFvSJKW713fDhBt/?= =?us-ascii?q?8rmRc9CtWOE0zxIa2iRSU7GMNfSA0tpCnjYgBaF8nkelLdvGC54yIMFRXjLwp1?= =?us-ascii?q?Ifn+FpLPg8it2e2//5Lebx9UiDahfLh/MAi4oQLNu8cMnIBsMLwxyhzHontJf+?= =?us-ascii?q?RZ22ZlLk+Nkhj/+8m94odt/zxftPw9+cFAV776f7kjQrxDEDsmKWE169b1uhTF?= =?us-ascii?q?UACC+2ETUmQSkhpPHgjF8BT3VYr/vyfmquZw3jSRMNboRr4oRzut86ZrSAfpiC?= =?us-ascii?q?gZMT457HrXgdF0gK5CvR6tuwBzz4vSbY6SKfR+Y7jdfcsESmVdQsZfWStBAoam?= =?us-ascii?q?YIsOCeoKIOJUoob5qlcLqxa1GAuiC/71yjJQiXD206813eQvHw/FwQIuAc4BvW?= =?us-ascii?q?/Oo9npLqofS/y5wLXKwDjFcvhY2S396I/Nch05of+DR6l/cdDQyUYzCQzOk1Oe?= =?us-ascii?q?ppL4ND2VyOsNqHOb4PBmVeKzlmUqrAF/rSK0ycc2i4nGmpwaxkrC+ypn2Ik1K8?= =?us-ascii?q?O3SFVgYdG+FptQqzqXN4pwQsM4QmFnojw2yrMcuZOieiUB1Zopxxnaa/OdcoiI?= =?us-ascii?q?5AruVOeXITdihXJqYqizhxio8US4yuzzTMm00FFNriZfjtbMsXUN2hrO4caEUv?= =?us-ascii?q?tw5lmt1SqL2gzJ6exJIVo4mbTGJ5Mg2LI8i5gevEDFEyTrgkv5lrWWeV8h+uWw?= =?us-ascii?q?6+TofLHmppiEOo9xkA7+M6AultWmAeQkLgQCRmab9fm+2bDn50H5T7JKjvo5kq?= =?us-ascii?q?ndrp/WP9gUpqm8AwNN04Yj7QiwDyu+3dgGgXUKKEhJdRGHgoTzJV3CPfH1Ae2i?= =?us-ascii?q?j1mulDpn3/XGMafgApXJIHjDirDhfbNl5k5S0gU81spf55NPCrEaIfLzX0jxuc?= =?us-ascii?q?fXDh88KQO0wuLnBM9h2YMZXGKDGrWZP7/KsV+U+uIvJPGBa5MPtzb4L/gp/vru?= =?us-ascii?q?jX4imV8BZqSpxpsWaHWgHvt8OUmZYHzsgs0AEWgQpAY+Qvbq2xW+VmtzYHC9Va?= =?us-ascii?q?V01DEyDo3uWYfRRomrj+bQgQ+xGppRY2pLEF/KF3r0IcHMSvINbjmRM+djmzoJ?= =?us-ascii?q?TqS7RoI9kxqpsVzU0b1ie8Td8DcZvp+r8NU9yeDIjhg06XQgIc2XyWCGQidQk1?= =?us-ascii?q?QGSiQt1aZjiU170FaKl6Zi1a8LXedP7u9EB19pfaXXyPZ3XpWvAw8=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BUAQB/dvpYhrPYVdFcGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBFgEBAQMBAQEJAQEBg3oQgQyDZ4oVkWeCPJMogjuCQoM2AoQLPxgBAQE?= =?us-ascii?q?BAQEBAQEBARIBAQEICwsIKC+CMyKCQAEBAgIBI0sLBQsLCwMHAgENHQICIhIBB?= =?us-ascii?q?QEKCggGARISAgqJZgMNCA6dPz+MBYImhzEDg28BAQgBAQEBAQEiEos3h12CXwW?= =?us-ascii?q?HXQyBSnKHOIRshnhwhieLb4JVjwKSUTOBFQ8QgT5DJFUYBoRKHYFjQDWJNgEBA?= =?us-ascii?q?Q?= X-IPAS-Result: =?us-ascii?q?A0BUAQB/dvpYhrPYVdFcGgEBAQECAQEBAQgBAQEBFgEBAQM?= =?us-ascii?q?BAQEJAQEBg3oQgQyDZ4oVkWeCPJMogjuCQoM2AoQLPxgBAQEBAQEBAQEBARIBA?= =?us-ascii?q?QEICwsIKC+CMyKCQAEBAgIBI0sLBQsLCwMHAgENHQICIhIBBQEKCggGARISAgq?= =?us-ascii?q?JZgMNCA6dPz+MBYImhzEDg28BAQgBAQEBAQEiEos3h12CXwWHXQyBSnKHOIRsh?= =?us-ascii?q?nhwhieLb4JVjwKSUTOBFQ8QgT5DJFUYBoRKHYFjQDWJNgEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,231,1488841200"; d="scan'208,217";a="269986432" Received: from mail-qt0-f179.google.com ([209.85.216.179]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 21 Apr 2017 23:18:06 +0200 Received: by mail-qt0-f179.google.com with SMTP id y33so79125884qta.2 for ; Fri, 21 Apr 2017 14:18:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kiq1srSTae8iRwZovgGleX+PNtdAgmJ9DTMQLZL65qk=; b=qccv5/gXCyWA+f+aQitvoMAOIra3xKyGdLh9diEN6yYmJUouyHkuaww5/2gSQm0EVJ wqwMi191OGbV2rlTTa1U61zeCe87nrS860cyooIcu0mAxSH5pFQTiTfuRdAxn0rRvz1S Rh5sPvCe04JV4qaWDfylqHZnd0+3d8m8qSLzsQrcTs+km7BXxeDAUJnBISTgN+plI6pa f3CSQOB8q5XRLfsSYG9jAsg3A/SObRXluzc4MBexI7CLFFAIigAd9py9LgEurqKS/6HC 79hCPmARfwVrRw+UlTA6W4PmW7OeKo2TKckLc6LcGQWJiE1BCEIumfNGSj2N3iddyfmJ aGwA== X-Gm-Message-State: AN3rC/7ZugDpx1WdjwEByObJ2JL8XSx+VYlHjrK64x4N7Udmwt5bkNdq PpcOP0vO2wuobn5SiAIMiwRtCbkovnug X-Received: by 10.200.51.183 with SMTP id c52mr15491240qtb.252.1492809485363; Fri, 21 Apr 2017 14:18:05 -0700 (PDT) MIME-Version: 1.0 References: <58FA5C34006504E200390857_0_88872@msllnjpmsgsv06> In-Reply-To: <58FA5C34006504E200390857_0_88872@msllnjpmsgsv06> From: Fabrice Le Fessant Date: Fri, 21 Apr 2017 21:17:54 +0000 Message-ID: To: Hongbo Zhang , yminsky@janestreet.com Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=001a1147309a17b0bd054db3cbd2 Subject: Re: [Caml-list] PPX is harmful to our community in the long term --001a1147309a17b0bd054db3cbd2 Content-Type: text/plain; charset=UTF-8 A lot of people use `autoconf` to generate `./configure` scripts, and the standard practice is to keep the `./configure` script so that people don't need to run `autoconf` to just compile and install the software. Maybe projects could do the same with ppx, i.e. store pre-processed files in the project sources so that the ppx would only be needed when the developer modifies the sources. For example, there could be a `_ppx` directory, where pre-processed files would be stored under the hash of a combination of their original source code and the `-ppx` arguments. The compiler (or the build system) would use these files when available instead of calling the ppx. That might reduce the problem at least for `opam`, since users are not supposed to edit the packages when installing them. On Fri, Apr 21, 2017 at 9:24 PM Hongbo Zhang (BLOOMBERG/ 731 LEX) < hzhang295@bloomberg.net> wrote: > Yes, when you never depend on other people's PPX, it is perfectly fine to > provide a customized > suite of PPX. > Think about the software which only works against 4.03, 4.04, this is > equivalent to say that you release > a c++ library only works with gcc 7 while most enterprises are still using > 4.8, nobody even think it is a > serious piece of software. > It is a different story in Haskell deriving or Scheme macro system, there > is no issue that you software > in use today will be not compilable in the future. > > From: yminsky@janestreet.com At: 04/21/17 15:12:29 > To: Hongbo Zhang (BLOOMBERG/ 731 LEX) > Cc: caml-list@inria.fr > Subject: Re: [Caml-list] PPX is harmful to our community in the long term > > I understand the frustration, but I think your conclusion is > misplaced. PPXs are massively helpful when building serious software. > Having automatic generation of pretty-printers, comparison functions, > hash functions, binary protocols, and the like is a huge win for both > programmer efficiency and correctness. The Haskell folk aren't wrong > to care about deriving, and the schemers aren't crazy to want their > macro systems. > > In short, I think abandoning syntactic abstractions is madness. > > I agree that the portability problems are serious and should be > addressed, but ocaml-migrate-parsetree seems like a solid step in the > right direction. > > y > > On Fri, Apr 21, 2017 at 11:41 AM, Hongbo Zhang (BLOOMBERG/ 731 LEX) > wrote: > > Dear OCaml developers: > > Given that bitten by PPX from time to time, finally, I think it is a > time to > > spend two hours sharing my experience with PPX and why you(the OCaml > library > > developer) should avoid PPX as much as you can. > > > > Here is a story I just experienced this morning, I tried to install a > > package from opam, and it complained my compiler is too old - 4.02.3, to > be > > honest, 4.02.3 is still a pretty modern OCaml compiler, even debian > stable > > still stays on 4.01. Anyway, I switched to 4.04.1, after half an hour, it > > failed to compile again, complaning about some ppx error message. This is > > not my first time experience, and finally it made me to write an essay > about > > why PPX is harmful. > > PPX is a compiler plugin, it imposes a very large compiler surface API to > > your library, and we don't have any backward compatibility guarantee from > > the compiler, which means your library will only work against a specific > > compiler. Even worse, OCaml is an elegant but small community, we don't > have > > too many maintainers for a library, if you have a library which relies on > > PPX (the dependency chain could be really really huge, for example, > > ppx_metaquot depends on typing environment, you can find lots of stories > > about node_modules in Node community), it will probably not work against > > next version of OCaml compiler, and it will be a huge maintenance > overhead > > for other people to pick it up. > > > > OCaml is already a very expressive language, probably more expressive > than > > any other mainstream language, (Go, Java, C/C++, etc), it is fine to > write > > some boilerplate code, or we can cut PPX as a dev dependency, after your > > PPXed your code, check in the generated source code(via -dsource), so it > > will not bring dependency to end users. > > There are some valid use cases of PPX, for example, in BuckleScript or > > JS_of_OCaml, we want to customize OCaml language a bit for external FFI, > or > > if you have a very large team, and committed effort to maintain your PPX. > > Happy hacking in OCaml without PPX, Thanks -- Hongbo > > > > > > -- > 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 > > --001a1147309a17b0bd054db3cbd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A lot of people use `autoconf` to generate `./configure` s= cripts, and the standard practice is to keep the `./configure` script so th= at people don't need to run `autoconf` to just compile and install the = software. Maybe projects could do the same with ppx, i.e. store pre-process= ed files in the project sources so that the ppx would only be needed when t= he developer modifies the sources. For example, there could be a `_ppx` dir= ectory, where pre-processed files would be stored under the hash of a combi= nation of their original source code and the =C2=A0`-ppx` arguments. The co= mpiler (or the build system) would use these files when available instead o= f calling the ppx. That might reduce the problem at least for `opam`, since= users are not supposed to edit the packages when installing them.
On Fri, Apr 21, 2017 at 9:24 P= M Hongbo Zhang (BLOOMBERG/ 731 LEX) <hzhang295@bloomberg.net> wrote:
Yes, when you never depend on other people's PPX= , it is perfectly fine to provide a customized
suite of PPX.
Think about the software which only works against 4.03, 4.04, this i= s equivalent to say that you release
a c++ library only works wit= h gcc 7 while most enterprises are still using 4.8,=C2=A0nobody even think = it is a=C2=A0
serious piece of software.
It is a differ= ent story in Haskell deriving or Scheme macro system, there is no issue tha= t you software=C2=A0
in use today will be not compilable in the f= uture.

<= div class=3D"m_-4726823415836708255bbg-rte-fold-summary">From: yminsky@janestreet.com = At: 04/21/17 15:12:29
To: Hongbo Zhang (BLOOMBERG/ 731 LEX)
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] PPX is harmf= ul to our community in the long term
I understand the frustration, but I thi= nk your conclusion is
misplaced. PPXs are massively helpful when buildin= g serious software.
Having automatic generation of pretty-printers, comp= arison functions,
hash functions, binary protocols, and the like is a hu= ge win for both
programmer efficiency and correctness. The Haskell folk = aren't wrong
to care about deriving, and the schemers aren't cra= zy to want their
macro systems.

In short, I think abandoning synt= actic abstractions is madness.

I agree that the portability problems= are serious and should be
addressed, but ocaml-migrate-parsetree seems = like a solid step in the
right direction.

y

On Fri, Apr 21= , 2017 at 11:41 AM, Hongbo Zhang (BLOOMBERG/ 731 LEX)
<hzhang295@bloomberg.net&= gt; wrote:
> Dear OCaml developers:
> Given that bitten by PPX = from time to time, finally, I think it is a time to
> spend two hours= sharing my experience with PPX and why you(the OCaml library
> devel= oper) should avoid PPX as much as you can.
>
> Here is a story = I just experienced this morning, I tried to install a
> package from = opam, and it complained my compiler is too old - 4.02.3, to be
> hone= st, 4.02.3 is still a pretty modern OCaml compiler, even debian stable
&= gt; still stays on 4.01. Anyway, I switched to 4.04.1, after half an hour, = it
> failed to compile again, complaning about some ppx error message= . This is
> not my first time experience, and finally it made me to w= rite an essay about
> why PPX is harmful.
> PPX is a compiler p= lugin, it imposes a very large compiler surface API to
> your library= , and we don't have any backward compatibility guarantee from
> t= he compiler, which means your library will only work against a specific
= > compiler. Even worse, OCaml is an elegant but small community, we don&= #39;t have
> too many maintainers for a library, if you have a librar= y which relies on
> PPX (the dependency chain could be really really = huge, for example,
> ppx_metaquot depends on typing environment, you = can find lots of stories
> about node_modules in Node community), it = will probably not work against
> next version of OCaml compiler, and = it will be a huge maintenance overhead
> for other people to pick it = up.
>
> OCaml is already a very expressive language, probably m= ore expressive than
> any other mainstream language, (Go, Java, C/C++= , etc), it is fine to write
> some boilerplate code, or we can cut PP= X as a dev dependency, after your
> PPXed your code, check in the gen= erated source code(via -dsource), so it
> will not bring dependency t= o end users.
> There are some valid use cases of PPX, for example, in= BuckleScript or
> JS_of_OCaml, we want to customize OCaml language a= bit for external FFI, or
> if you have a very large team, and commit= ted effort to maintain your PPX.
> Happy hacking in OCaml without PPX= , Thanks -- Hongbo
>
>

https://sympa.inria.fr/sympa/arc/caml-list
Beginner'= s list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: = http://cam= l.inria.fr/bin/caml-bugs
--001a1147309a17b0bd054db3cbd2--