caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jacques Carette <carette@mcmaster.ca>
To: Yaron Minsky <yminsky@janestreet.com>,
	Anil Madhavapeddy <anil@recoil.org>
Cc: Olaf Hering <olaf@aepfle.de>,
	Fabrice Le Fessant <Fabrice.Le_fessant@inria.fr>,
	Hongbo Zhang <hzhang295@bloomberg.net>,
	"caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] PPX is harmful to our community in the long term
Date: Fri, 28 Apr 2017 10:55:44 -0400	[thread overview]
Message-ID: <ab9571d8-81d4-810a-92e0-02dfbfb3c791@mcmaster.ca> (raw)
In-Reply-To: <CACLX4jSFgL5epuhFE9EFNBF-8rwDCxm8-SQcdrhc3H6Lp-gquA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3638 bytes --]

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 <anil@recoil.org 
> <mailto:anil@recoil.org>> wrote:
>
>     On 28 Apr 2017, at 12:07, Olaf Hering <olaf@aepfle.de
>     <mailto: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 <http://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 <http://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
>
>


[-- Attachment #2: Type: text/html, Size: 5926 bytes --]

  reply	other threads:[~2017-04-28 14:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21 19:23 Hongbo Zhang (BLOOMBERG/ 731 LEX)
2017-04-21 21:17 ` Fabrice Le Fessant
2017-04-28 11:07   ` Olaf Hering
2017-04-28 13:04     ` Anil Madhavapeddy
2017-04-28 14:50       ` Yaron Minsky
2017-04-28 14:55         ` Jacques Carette [this message]
2017-05-11  9:37           ` Jeremie Dimino
  -- strict thread matches above, loose matches on Subject: below --
2017-04-23  0:06 Hongbo Zhang (BLOOMBERG/ 731 LEX)
2017-04-23  1:25 ` Yaron Minsky
2017-04-22 14:47 Hongbo Zhang (BLOOMBERG/ 731 LEX)
2017-04-22 19:47 ` Robert Muller
2017-04-23  1:30   ` Yaron Minsky
2017-04-21 21:48 Hongbo Zhang (BLOOMBERG/ 731 LEX)
2017-04-21 23:10 ` Emilio Jesús Gallego Arias
2017-04-22 12:49   ` Serge Sivkov
2017-04-21 15:41 Hongbo Zhang (BLOOMBERG/ 731 LEX)
2017-04-21 16:04 ` Yotam Barnoy
2017-04-21 16:43   ` Gerd Stolpmann
2017-04-21 17:11   ` Alain Frisch
2017-04-21 18:28     ` Jeremie Dimino
2017-04-21 16:55 ` Francois BERENGER
2017-04-21 19:11 ` Yaron Minsky
2017-04-21 19:22 ` Emilio Jesús Gallego Arias

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ab9571d8-81d4-810a-92e0-02dfbfb3c791@mcmaster.ca \
    --to=carette@mcmaster.ca \
    --cc=Fabrice.Le_fessant@inria.fr \
    --cc=anil@recoil.org \
    --cc=caml-list@inria.fr \
    --cc=hzhang295@bloomberg.net \
    --cc=olaf@aepfle.de \
    --cc=yminsky@janestreet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).