caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Hongbo Zhang (BLOOMBERG/ 731 LEX)" <hzhang295@bloomberg.net>
To: Fabrice.Le_fessant@inria.fr, yminsky@janestreet.com
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] PPX is harmful to our community in the long term
Date: Fri, 21 Apr 2017 21:48:19 -0000	[thread overview]
Message-ID: <58FA7E22024A00360039082F_0_1166040@n472> (raw)

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

Yes, that's exactly what I suggested in the beginning! 
calling it 'madness' is disrespectful 

----- Original Message -----
From: Fabrice Le Fessant <Fabrice.Le_fessant@inria.fr>
To: HONGBO ZHANG, yminsky@janestreet.com
CC: caml-list@inria.fr
At: 21-Apr-2017 17:18:32


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)
<hzhang295@bloomberg.net> 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



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

             reply	other threads:[~2017-04-21 21:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21 21:48 Hongbo Zhang (BLOOMBERG/ 731 LEX) [this message]
2017-04-21 23:10 ` Emilio Jesús Gallego Arias
2017-04-22 12:49   ` Serge Sivkov
  -- 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 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
2017-05-11  9:37           ` Jeremie Dimino
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=58FA7E22024A00360039082F_0_1166040@n472 \
    --to=hzhang295@bloomberg.net \
    --cc=Fabrice.Le_fessant@inria.fr \
    --cc=caml-list@inria.fr \
    --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).