[ghc-steering-committee] Plugin recompilation avoidance interface (#108)

[Iavor Diatchki]

Hello,

I've been really busy at work so I haven't had time to look at this in
detail, but I think the proposal address an important problem that I've
actually encountered, so I think it is great that we are doing something
about it, so I am +1 in principle.

-Iavor

On Fri, Mar 2, 2018 at 9:05 AM Ben Gamari <ben at well-typed.com> wrote:

> Ben Gamari <ben at well-typed.com> writes:
>
> > Hello everyone,
> >
> > I have been assigned as the shepard for proposal #108. This proposes a
> > change in GHC's plugin interface allowing plugins greater control over
> > recompilation, significantly improving compilation times for projects
> > relying on compiler plugins.
> >
> >
> > Summary:
> >
> > The proposal suggests that the existing fields of the `ghc` package's
> > Plugin.Plugin type be wrapped with a type capturing a function computing
> > the plugin's recompilation desired behavior,
> >
> >    data PluginRecompile = ForceRecompile
> >                         | NoForceRecompile
> >                         | MaybeRecompile Fingerprint
> >
> > GHC can then use this recompilation information to decide whether
> > evaluating the plugin (and consequently invalidating any existing
> > compilation artifacts) is necessary.
> >
> >
> > Opinion & recommendation:
> >
> > The proposal addresses a long-standing limitation (#7414) of the GHC
> > plugin interface which has become increasingly visible to users in
> > recent years. While the particular approach proposed breaks existing
> > plugin users, it is expressive enough to allow GHC to perform more
> > aggressive recompilation avoidance in the future [1]. Moreover, the
> > smart constructors proposed should make for a reasonably smooth
> > migration path.
> >
> > Given that the plugins appears to have buy-in from a few notable plugin
> > authors, I recommend that we accept this proposal.
> >
> I've pinged a number of prominent plugin authors and heard no reply.
> Therefore, I would again recommend that we accept.
>
> Cheers,
>
> - Ben
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180302/1494ea3f/attachment.html>