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

[Simon Marlow]

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.

Cheers
Simon

On 2 March 2018 at 17:49, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:

> 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
>>
>
> _______________________________________________
> 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/20180305/5719e5b0/attachment.html>