<div dir="ltr"><div><div>Also +1 from me in principle - with the caveat that I haven't written any plugins, but I am quite familiar with how recompilation avoidance works. It's an important issue to address, and I didn't spot any obvious problems with the design.<br><br></div>Cheers<br></div>Simon<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 2 March 2018 at 17:49, Iavor Diatchki <span dir="ltr"><<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Iavor</div></font></span></div><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Fri, Mar 2, 2018 at 9:05 AM Ben Gamari <<a href="mailto:ben@well-typed.com" target="_blank">ben@well-typed.com</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">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></div></div><span class="">
______________________________<wbr>_________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@<wbr>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-<wbr>bin/mailman/listinfo/ghc-<wbr>steering-committee</a><br>
</span></blockquote></div>
<br>______________________________<wbr>_________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@<wbr>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-<wbr>bin/mailman/listinfo/ghc-<wbr>steering-committee</a><br>
<br></blockquote></div><br></div>