<div dir="ltr">Hello,<div><br></div><div>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.</div><div><br></div><div>-Iavor</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 2, 2018 at 9:05 AM Ben Gamari <<a href="mailto:ben@well-typed.com">ben@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ben Gamari <<a href="mailto:ben@well-typed.com" target="_blank">ben@well-typed.com</a>> writes:<br>
<br>
> Hello everyone,<br>
><br>
> I have been assigned as the shepard for proposal #108. This proposes a<br>
> change in GHC's plugin interface allowing plugins greater control over<br>
> recompilation, significantly improving compilation times for projects<br>
> relying on compiler plugins.<br>
><br>
><br>
> Summary:<br>
><br>
> The proposal suggests that the existing fields of the `ghc` package's<br>
> Plugin.Plugin type be wrapped with a type capturing a function computing<br>
> the plugin's recompilation desired behavior,<br>
><br>
>    data PluginRecompile = ForceRecompile<br>
>                         | NoForceRecompile<br>
>                         | MaybeRecompile Fingerprint<br>
><br>
> GHC can then use this recompilation information to decide whether<br>
> evaluating the plugin (and consequently invalidating any existing<br>
> compilation artifacts) is necessary.<br>
><br>
><br>
> Opinion & recommendation:<br>
><br>
> The proposal addresses a long-standing limitation (#7414) of the GHC<br>
> plugin interface which has become increasingly visible to users in<br>
> recent years. While the particular approach proposed breaks existing<br>
> plugin users, it is expressive enough to allow GHC to perform more<br>
> aggressive recompilation avoidance in the future [1]. Moreover, the<br>
> smart constructors proposed should make for a reasonably smooth<br>
> migration path.<br>
><br>
> Given that the plugins appears to have buy-in from a few notable plugin<br>
> authors, I recommend that we accept this proposal.<br>
><br>
I've pinged a number of prominent plugin authors and heard no reply.<br>
Therefore, I would again recommend that we accept.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>