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

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 wrote:

Ben Gamari 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee