Re: [Caml-list] PPX is harmful to our community in the long term

[Fabrice Le Fessant <Fabrice.Le_fessant@inria.fr>]

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

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: 6754 bytes --]