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 B35F17FA5E for ; Fri, 28 Apr 2017 16:55:48 +0200 (CEST) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=carette@mcmaster.ca; spf=None smtp.mailfrom=carette@mcmaster.ca; spf=None smtp.helo=postmaster@FHSHC4H16-1.csu.mcmaster.ca Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of carette@mcmaster.ca) identity=pra; client-ip=130.113.22.3; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="carette@mcmaster.ca"; x-sender="carette@mcmaster.ca"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of carette@mcmaster.ca) identity=mailfrom; client-ip=130.113.22.3; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="carette@mcmaster.ca"; x-sender="carette@mcmaster.ca"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@FHSHC4H16-1.csu.mcmaster.ca) identity=helo; client-ip=130.113.22.3; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="carette@mcmaster.ca"; x-sender="postmaster@FHSHC4H16-1.csu.mcmaster.ca"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3A4lDpbhxkcELCAkLXCy+O+j09IxM/srCxBDY+r6Qd?= =?us-ascii?q?0uoWKfad9pjvdHbS+e9qxAeQG96Kt7Qc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q89pDXbAhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7Vq4/Vyi84Kh3SR/okC?= =?us-ascii?q?YHOCA/8GHLkcx7kaZXrAu8qxBj34LYZYeYP+d8cKzAZ9MXXXdPUNhfVyJBAY2y?= =?us-ascii?q?YYUAAOUDMulEronwvEEBoQekCAS2GO/ixD1Fi3nr1qM6yeQhFgTG0RQkEd0UrH?= =?us-ascii?q?vUtcj1O7kJUeuo0qTH1y/DYO1K2Tfh9ofDbxcsru2WUrJqb8XR1VUvGB3eg1WV?= =?us-ascii?q?tYPlOima1v8Rs2eF9epsT/6ghHQ+pgx3vzOhyMAsiozTiYIUzFDJ7SB5wYYyJd?= =?us-ascii?q?KkUkF7ZNqkH4BNtyGbM4t5X9kuQ2RsuCoi1rIGvpi7fCYLyJQo2h7fceKIf5KS?= =?us-ascii?q?7R3/TOqRIy13hHR7d7Kkmxay61avxfPgVsWuzFlKqS9Fn9/RvX4Ozxze8tWLR/?= =?us-ascii?q?Vh8ku7xDqDyg7e5vtaLUwqj6bWJYYtzqM+m5YPq0jPAzL6lUvsgKOIaEko4Pak?= =?us-ascii?q?5ur5brjgu5SSLZV7ihvkPaQrgsG/Afo3MgwJX2WD+eqy1qDt80/nTbhFjPM6j6?= =?us-ascii?q?jUvInHKcgBuqG5GBJV3pwm6xmjCjepys8YnWUZI1JfYh6Ik5LmN0nPIPD+E/i/?= =?us-ascii?q?n0yhnCplyvzaJLHtH4jBI3bZnLv/Y7px8UBRxBI2zd9F5pJUDr8BIOj0Wk/0rN?= =?us-ascii?q?HXEgU2MxaqzOb7FNVyyJgTWWeTDa+cKqzSqkOI6fw1I+WWeIAaoi7xK+I56P72?= =?us-ascii?q?kX85hVgdcLG10pQNbXC4Gu1qI0GYYXr3ntcMCnwKvwo7TOzyklKOSz9TZ3CoX6?= =?us-ascii?q?I9/D43EoymDZ3bTIC3nLOBxDu7HoFRZm1eDlCDD3noeJufW/cXci2SJNRskz0F?= =?us-ascii?q?VbikUIAhzwuhuBX7y7phNOrU+zcXuYjt1NhvtKXvkkQD/CZzCYy40meWTHA8yn?= =?us-ascii?q?INRjkt37FXo0V7x0yfy6V1n7pTEtkFo7tgVAY+fbvVw+xzFdnqVw7Nb5/dQVCn?= =?us-ascii?q?Rv28DDo2T9Z3xMUBNRVTAdKn2zLK1DO3DqRdvLWRCYAo/+qI1HHrKtphxl7D36?= =?us-ascii?q?wolEUrWI1EPDv11eZE6wHPCtuRwA2inKGwePFZhXaV+Q=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AABGVwNZbwMWcYJeGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBFQEBAQECAQEBAQgBAQEBhAuBDAeDYZtnl3wsgkKDNgKEMEIVAQE?= =?us-ascii?q?BAQEBAQEBAQESAQwLCQgLHS+CMyIBgj8BAQEBAgEOFUIUBQsLDgonAwICRhEGA?= =?us-ascii?q?QwBBQIBARCKAwgOryuCJiuKXgEBAQEBAQEBAQEBAQEBAQEBAQEBAR0JAYhegm+?= =?us-ascii?q?FHYJIgl8FnVGHG45KiCSGY4wCiCc1gSwuIAguRIcMWYZfAYEMAQEB?= X-IPAS-Result: =?us-ascii?q?A0D1AABGVwNZbwMWcYJeGQEBAQEBAQEBAQEBBwEBAQEBFQE?= =?us-ascii?q?BAQECAQEBAQgBAQEBhAuBDAeDYZtnl3wsgkKDNgKEMEIVAQEBAQEBAQEBAQESA?= =?us-ascii?q?QwLCQgLHS+CMyIBgj8BAQEBAgEOFUIUBQsLDgonAwICRhEGAQwBBQIBARCKAwg?= =?us-ascii?q?OryuCJiuKXgEBAQEBAQEBAQEBAQEBAQEBAQEBAR0JAYhegm+FHYJIgl8FnVGHG?= =?us-ascii?q?45KiCSGY4wCiCc1gSwuIAguRIcMWYZfAYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.37,388,1488841200"; d="scan'208,217";a="270966615" Received: from fhshc4h16-1.csu.mcmaster.ca ([130.113.22.3]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES256-SHA; 28 Apr 2017 16:55:47 +0200 Received: from [130.113.169.63] (130.113.22.232) by fhshc.csu.mcmaster.ca (130.113.22.3) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 28 Apr 2017 10:55:45 -0400 To: Yaron Minsky , Anil Madhavapeddy References: <58FA5C34006504E200390857_0_88872@msllnjpmsgsv06> <20170428110718.GB13305@aepfle.de> <05BE6A9C-9AFB-4AD2-B577-23F4B88B86B3@recoil.org> CC: Olaf Hering , Fabrice Le Fessant , Hongbo Zhang , "caml-list@inria.fr" From: Jacques Carette Message-ID: Date: Fri, 28 Apr 2017 10:55:44 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D6BCC95E74E8DDBDD823086B" X-Originating-IP: [130.113.22.232] X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23036.004 X-TM-AS-Result: No--11.656700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: Re: [Caml-list] PPX is harmful to our community in the long term --------------D6BCC95E74E8DDBDD823086B Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit As co-author of the now-obsolete pa_monad, I emphatically agree! Jacques On 2017-04-28 10:50 AM, Yaron Minsky wrote: > We're very similar, except that we now do use a monadic syntax pretty > pervasively. I wrote about this here: > > https://blogs.janestreet.com/let-syntax-and-why-you-should-use-it/ > > and am if anything more convinced that it's a worthwhile idiom. Monads > and Applicatives are useful in so many places (beyond Async and Lwt) > that having syntactic support for them is really nice, especially for > the let .. and constructs. > > y > > On Fri, Apr 28, 2017 at 9:04 AM, Anil Madhavapeddy > wrote: > > On 28 Apr 2017, at 12:07, Olaf Hering > wrote: > > > > On Fri, Apr 21, Fabrice Le Fessant wrote: > > > >> 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 > > > > This is and was a huge mistake to promote 'configure&&make' > instead of > > autogen.sh&&configure&&make. Having a set of uptodate autotools > > installed is easy and cheap, they are not runtime dependencies. The > > result of that wrongdoing is a huge pile of broken and/or > incomplete configure.ac . > > Indeed -- we spent years in OpenBSD dealing with patching broken > versions > of libtool scripts that embedded incorrect behaviour on our > particular platforms, > and were stubbornly included in upstream distributions without > being regenerated. > > > Do not repeat that mistake, whatever it means in the OCaml world. > > A similar analogue in the OCaml world may be the inclusion of > autogenerated > files from _oasis. The inclusion of the autogenerated files like > myocamlbuild.ml > was a holdover from a pre-opam world when it was painful to > install all the > build dependencies of OASIS. > > Nowadays, it's quite easy to install oasis and run `oasis setup` > in a project > to get the latest build rules, and the checked in autogenerated > files only > get in the way and/or are increasingly complex due to having to > deal with > multiple OCaml versions (e.g. for String.lowercase vs > String.lowercase_ascii). > > Bundling pre-evaluated ppx output in a release tarball runs the > same risk... > > Our experience in Mirage with PPX has been to find a balance -- we > do not let > it proliferate beyond type_conv usage or ppx_cstruct for binary > formats. Some > libraries (such as the TLS stack) do not use it all. One of the > heaviest uses > of camlp4 in the past for us was the pa_lwt syntax extension, and > most libraries > have gone towards explicit Lwt.bind() calls instead of using the > ppx alternative. > > I'm hopeful that ocaml-migrate-parsetree will make it easier for > us to test > common libraries on dev versions of OCaml. In practise with 4.05, > it has been > non-ppx changes that have been blocking testing -- for instance > the close-on-exec > flag addition to the Unix module caused rippling breakage through > Lwt and other > platform libraries. That's not to say that PPX isn't a problem, > but it has > gotten significantly easier to deal with since Fred's work on > migrate-parsetree. > > regards, > Anil > > --------------D6BCC95E74E8DDBDD823086B Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
As co-author of the now-obsolete pa_monad, I emphatically agree!
Jacques

On 2017-04-28 10:50 AM, Yaron Minsky wrote:
We're very similar, except that we now do use a monadic syntax pretty pervasively. I wrote about this here:


and am if anything more convinced that it's a worthwhile idiom. Monads and Applicatives are useful in so many places (beyond Async and Lwt) that having syntactic support for them is really nice, especially for the let .. and constructs.

y

On Fri, Apr 28, 2017 at 9:04 AM, Anil Madhavapeddy <anil@recoil.org> wrote:
On 28 Apr 2017, at 12:07, Olaf Hering <olaf@aepfle.de> wrote:
>
> On Fri, Apr 21, Fabrice Le Fessant wrote:
>
>> 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
>
> This is and was a huge mistake to promote 'configure&&make' instead of
> autogen.sh&&configure&&make. Having a set of uptodate autotools
> installed is easy and cheap, they are not runtime dependencies. The
> result of that wrongdoing is a huge pile of broken and/or incomplete configure.ac.

Indeed -- we spent years in OpenBSD dealing with patching broken versions
of libtool scripts that embedded incorrect behaviour on our particular platforms,
and were stubbornly included in upstream distributions without being regenerated.

> Do not repeat that mistake, whatever it means in the OCaml world.

A similar analogue in the OCaml world may be the inclusion of autogenerated
files from _oasis.  The inclusion of the autogenerated files like myocamlbuild.ml
was a holdover from a pre-opam world when it was painful to install all the
build dependencies of OASIS.

Nowadays, it's quite easy to install oasis and run `oasis setup` in a project
to get the latest build rules, and the checked in autogenerated files only
get in the way and/or are increasingly complex due to having to deal with
multiple OCaml versions (e.g. for String.lowercase vs String.lowercase_ascii).

Bundling pre-evaluated ppx output in a release tarball runs the same risk...

Our experience in Mirage with PPX has been to find a balance -- we do not let
it proliferate beyond type_conv usage or ppx_cstruct for binary formats.  Some
libraries (such as the TLS stack) do not use it all. One of the heaviest uses
of camlp4 in the past for us was the pa_lwt syntax extension, and most libraries
have gone towards explicit Lwt.bind() calls instead of using the ppx alternative.

I'm hopeful that ocaml-migrate-parsetree will make it easier for us to test
common libraries on dev versions of OCaml.  In practise with 4.05, it has been
non-ppx changes that have been blocking testing -- for instance the close-on-exec
flag addition to the Unix module caused rippling breakage through Lwt and other
platform libraries.  That's not to say that PPX isn't a problem, but it has
gotten significantly easier to deal with since Fred's work on migrate-parsetree.

regards,
Anil



--------------D6BCC95E74E8DDBDD823086B--