Re: [Caml-list] Recent hooks design and general github PR issues

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

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

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

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