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 9116D7FA5E for ; Thu, 11 May 2017 11:37:08 +0200 (CEST) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=jdimino@janestreet.com; spf=Pass smtp.mailfrom=jdimino@janestreet.com; spf=None smtp.helo=postmaster@mxout3.mail.janestreet.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jdimino@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jdimino@janestreet.com"; x-sender="jdimino@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of jdimino@janestreet.com designates 38.105.200.229 as permitted sender) identity=mailfrom; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jdimino@janestreet.com"; x-sender="jdimino@janestreet.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@mxout3.mail.janestreet.com) identity=helo; client-ip=38.105.200.229; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jdimino@janestreet.com"; x-sender="postmaster@mxout3.mail.janestreet.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3A8y2Q3BQ/gegcwWHxxbtC7UWoUdpsv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa6zZxaN2/xhgRfzUJnB7Loc0qyN4vymATRIyK3CmUhKSIZLWR4BhJ?= =?us-ascii?q?detC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+?= =?us-ascii?q?KPjrFY7OlcS30P2594HObwlSijewZbx/IA+qoQnNq8IbnZZsJqEtxxXTv3BGYf?= =?us-ascii?q?5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM30u683wqRbD?= =?us-ascii?q?VwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xymp4rx1QxH0li?= =?us-ascii?q?gIKz858HnWisNuiqJbvAmhrAF7z4LNfY2ZKOZycqbbcNgHR2ROQ9xRWjRDDYOy?= =?us-ascii?q?b4UBAekPM/tGoYbhvFYBtweyCBO2Ce/z1jNFhHn71rA63eQ7FgHG2RQtEdYQv3?= =?us-ascii?q?TOstr1MaYSXv6ox6fGzDXDavJW2TH66IPVdR0ho+yDXbN1ccrQz0kvEBjIjleK?= =?us-ascii?q?pozjITyVzfgNs3KF4OV+SeKjkXIoqwZ0ojW2wMonl4fHhoUQyl/e9CV5xp44Jd?= =?us-ascii?q?i4SU58fdGrCp5QtyWBOItrQ8MiR3xntDw/yr0CoZK0YC8KyJIpxx7eZPyHbpKI?= =?us-ascii?q?7Qz5WOmLPTh0nH1leLOjhxay7Eiv0ffwWdWz0FZPtiZFkMPDtnYT2BzI9siHUO?= =?us-ascii?q?Vy8Vm92TqVyw/T7eRELEYpnqTYM54s2rA9m5kJvUjeAiP7mF/6gLGKekk44OSk?= =?us-ascii?q?9frrb7H+qpKeOIJ4kBzyProul8ClAuk0LBICUmmf9Om6ybbt51f2QK9Qgf0ziq?= =?us-ascii?q?TZsI7VJcAcpqOhBg9U3YEj6wujDzqoytgYmGMILFNBeB6djYjmIVfOL+7jDfej?= =?us-ascii?q?mVSjjilkx+zcMrL9BZXNK2DPkLbnfblj905R0AQ+wNNF655JFr0MIOj/VlHtuN?= =?us-ascii?q?DEFBM1LRK4zuL/BNV4zIweWGaPAqGDMKPVtF+F/uAvLPSNZI8QuTb9Lf8l6uXs?= =?us-ascii?q?jXAjn18SY7Kp3YcNaH+mAPtmP1+VbmbrgtcECWsKpBYxTPT2iF2eVj5ef2q9UL?= =?us-ascii?q?g55jE/EY6mCYbDRpuxgLGaxye6HphWZnhcBVyWEHfocZ+EW/YWZy6ILM9hiG9M?= =?us-ascii?q?ab/0aYYqzAyjr0fRwqBqMvbZsnkTvIjuyMR4z+jYkBgp6TFuSc+UhTKjVWZxy0?= =?us-ascii?q?EFXTIz3a03jU14y1GEmfx6j/1dFNpUz/FAVAohKYTRwvA8ANf3DFGSNuyVQUqr?= =?us-ascii?q?F431SQo6Scg8lppXOx5w?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAwCxLxRZfeXIaSZdHAEBBAEBCgEBF?= =?us-ascii?q?wEBBAEBCgEBhAyBDAeDYptwgmiNVIU4gg8sgkKDNgKFAgdAFwEBAQEBAQEBAQE?= =?us-ascii?q?BEgEBCRYIV4IzIgGCPwEBAQECAQ4VHQEBIxQBBAsLCw0qAgIiEgEFARwGExQHi?= =?us-ascii?q?X8IAwukJz+LHWqCJiuCXgEBBYdkAQEBAQEBAQEBAQEBAQEBAQEBAQEBFQgShk2?= =?us-ascii?q?EeYUQgmWCYJ4PhxyLf4JZiCmGaZJ7FB+BFSABgUAvIAgZFUYZBoQeKg8cgWR1i?= =?us-ascii?q?RkBAQE?= X-IPAS-Result: =?us-ascii?q?A0CWAwCxLxRZfeXIaSZdHAEBBAEBCgEBFwEBBAEBCgEBhAy?= =?us-ascii?q?BDAeDYptwgmiNVIU4gg8sgkKDNgKFAgdAFwEBAQEBAQEBAQEBEgEBCRYIV4IzI?= =?us-ascii?q?gGCPwEBAQECAQ4VHQEBIxQBBAsLCw0qAgIiEgEFARwGExQHiX8IAwukJz+LHWq?= =?us-ascii?q?CJiuCXgEBBYdkAQEBAQEBAQEBAQEBAQEBAQEBAQEBFQgShk2EeYUQgmWCYJ4Ph?= =?us-ascii?q?xyLf4JZiCmGaZJ7FB+BFSABgUAvIAgZFUYZBoQeKg8cgWR1iRkBAQE?= X-IronPort-AV: E=Sophos;i="5.38,323,1491256800"; d="scan'208,217";a="272635196" Received: from mxout3.mail.janestreet.com ([38.105.200.229]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 May 2017 11:37:06 +0200 Received: from [172.27.56.68] (helo=tot-qpr-mailcore1) by mxout3.mail.janestreet.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1d8kWu-00048k-In for caml-list@inria.fr; Thu, 11 May 2017 05:37:04 -0400 X-JS-Flow: external X-JS-Scanner-attachment: (ok) No attachments Received: by tot-qpr-mailcore1 with ocaml/mailcore/mailcore 1.0+90 (160ed8e8fef2) (envelope-from ) id BZFDDA-AatZF9-R4; 2017-05-11 05:37:04.575800-04:00 Received: from mail-wm0-f69.google.com ([74.125.82.69]) by mxgoog1.mail.janestreet.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1d8kWu-0006y0-Dp for caml-list@inria.fr; Thu, 11 May 2017 05:37:04 -0400 Received: by mail-wm0-f69.google.com with SMTP id v4so5042477wmb.8 for ; Thu, 11 May 2017 02:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gkSu1zHJVNw1CrCyiYJnVLBvU2j8BLvKqijp6NY7R6I=; b=GGLpYwp9d55WvBEUnBd+QsxHThE/JsrHDq4TydOAQ1dWwHAXQLJ37FD4KdbGguVOO/ u01fN4ardCaPtZvmaxY9N9zNAjYsWX+i3hSxemllKDVQOic7NCcs+ZmMUX/BV1r1d2iN sLFGgcY9p4yuFHeQWoQYlyLdr1YxGHauhiHuA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gkSu1zHJVNw1CrCyiYJnVLBvU2j8BLvKqijp6NY7R6I=; b=nAoYelkUvGcFfv+a5pRzb6jgwrJTjVB70sO1MG2QigaWtAcIa5ipocFwrF2U4ZmM70 7C+52zzEvCDOxbj9j7A0zFupilgc9i575nlYnhy1rhNdwiuVzH12DuJ1SAGLN7P4CChc 8NhWDZreg8KCs2ECW7FyPpXahYZ6XSuLUYnFUolGFWAtcoeoXKmZJ8mKgtAms51Vk8OK XpwbBBlcAaCehbpJn0Eyny4hhaUtIXVHaYmqKeDFm8RYeaioAXVz0AiKpBsrxZ1QZK3C E+IyMdQgMpC3SyyNfc0lxMGBXriJ3axq8r54j5g2udxpicQlzILmTcUSab/WBUFuQ64O X83A== X-Gm-Message-State: AODbwcBSbm9OR7HiA73ka3U1/KP6RKj1snejeYwRteouuM/vzGAjg5o8 E0iEu2wfzzDB+9+TaherqDrUqXp3vzjosKWWYmawDpY1lydLhoOz//Ut6K1lIcQHYLeyzOK9xKd xYJdsKwR6A3l47Eot X-Received: by 10.25.211.12 with SMTP id k12mr4822759lfg.61.1494495423545; Thu, 11 May 2017 02:37:03 -0700 (PDT) X-Received: by 10.25.211.12 with SMTP id k12mr4822749lfg.61.1494495423311; Thu, 11 May 2017 02:37:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.199.9 with HTTP; Thu, 11 May 2017 02:37:02 -0700 (PDT) In-Reply-To: References: <58FA5C34006504E200390857_0_88872@msllnjpmsgsv06> <20170428110718.GB13305@aepfle.de> <05BE6A9C-9AFB-4AD2-B577-23F4B88B86B3@recoil.org> From:Jeremie Dimino Date: Thu, 11 May 2017 10:37:02 +0100 Message-ID: To:Jacques Carette Cc:Yaron Minsky , Anil Madhavapeddy , Olaf Hering , Fabrice Le Fessant , Hongbo Zhang , "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=001a113d8ddcd3502c054f3c54d7 X-JS-Exim-Data-Received: 2017-05-11 05:37:04-0400 X-JS-Processed-by: mailcore Subject: Re: [Caml-list] PPX is harmful to our community in the long term --001a113d8ddcd3502c054f3c54d7 Content-Type: text/plain; charset=UTF-8 Coming back to this thread. I had a simple idea recently for a ppx that makes it easy to do pattern matching on abstract types. I wrote some experiments here [1]. This essentially allows to make the AST fully abstract while still being able to deconstruct it conveniently. In fact the patterns are even nicer than ones matching the raw data type directly since you can build your own helper patterns. Making the AST abstract will allow to make the API evolve in a backward compatible way even though the underlying AST keeps changing. I just did some experiments for now. I think we'll eventually implement this solution properly and use it in our ppx code. [1] https://github.com/diml/ppx_view_pattern On Fri, Apr 28, 2017 at 3:55 PM, Jacques Carette wrote: > 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 >> >> > > -- Jeremie --001a113d8ddcd3502c054f3c54d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Coming back to this thread. I had a simple idea recentl= y for a ppx that makes it easy to do pattern matching on =C2=A0abstract typ= es. I wrote some experiments here [1]. This essentially allows to make the = AST fully abstract while still being able to deconstruct it conveniently. I= n fact the patterns are even nicer than ones matching the raw data type dir= ectly since you can build your own helper patterns.

Ma= king the AST abstract will allow to make the API evolve in a backward compa= tible way even though the underlying AST keeps changing.

=
I just did some experiments for now. I think we'll eventually implem= ent this solution properly and use it in our ppx code.

[1]=C2=A0https://gith= ub.com/diml/ppx_view_pattern

=
On Fri, Apr 28, 2017 at 3:55 PM, Jacques Carette= <carette@mcmaster.ca> wrote:
=20=20 =20=20=20=20 =20=20
As co-author of the= now-obsolete pa_monad, I emphatically agree!
Jacques


On 2017-04-28 10:50 AM, Yaron Minsky wrote:
=20=20=20=20=20=20
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, Ol= af Hering <olaf@aepf= le.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.=C2=A0 The inclusion of the autogenerated fil= es 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.=C2=A0 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.=C2=A0 In practise wi= th 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.=C2=A0 That's not to say that PPX isn= 9;t a problem, but it has
gotten significantly easier to deal with since Fred's work on migrate-parsetree.

regards,
Anil






--
Jeremie
--001a113d8ddcd3502c054f3c54d7--