On Tue, Jul 19, 2016 at 6:24 PM Yotam Barnoy <yotambarnoy@gmail.com> wrote:

See the comments at the bottom of
https://github.com/ocaml/ocaml/pull/668 by avsm and gasche

I replied to Gabriel, who was asking for a different API, that could be done, but is not my intent (OCamlPro needs what I implemented, not what he was discussing, so if somebody else wants to contribute the complementary approach, he is welcome), and Anil just said he didn't see the benefit of the interception hooks, which is (1) only one part of the PR (cplugins can be used to do other things, such as have a more portable version of OCamlPro's Memory Profiler) and (2) there are several examples on github.com/OCamlPro/ocp-cplugins that show that the restriction to the stdlib provides already interesting use cases.

See also Shinwell's concerns at the bottom of
https://github.com/ocaml/ocaml/pull/647

Mark was commenting on the maintainability of ppx at Jane Street, not about the maintainability of the ppx code inside the compiler. The discussion was diverging from the actual subject of the PR at that point.

. And note that since they are on separate PRs, they most likely did not see each others' comments, which is a problem.

I don't understand that part: there is no link between the two PRs, one is about plugins in the runtime, the other one about plugins in the compiler, which have completely different use cases and cost/benefits.

In general, I think the process has to be refined. As this is all part
of one feature, that feature should be discussed first before any
merging begins. And merging should not be done by the person
suggesting the feature.

I think it is quite common in the core team, especially before a code freeze. Check all the closed/merged PRs with the black tag "Spacetime prerequisite" for an easy example. The current process is to have at least one code review by another core developer and no strong objection by another core developer. I think it is a good trade-off between fast evolution while keeping good code quality.

Finally, about the maintainability, I think having plugins both in the runtime and the compiler will help externalizing some code from the distribution, thus decreasing the maintenance cost of the distribution, while allowing external contributors to extend the runtime and compiler through OPAM packages.

Best regards,

--Fabrice