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
>
>