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

Hi, we are all in agreement that we want plugins the ability to avoid recompilation. The open question is: Should this be on a per module basis? Or a per module-and-pass bases? The former has a simpler and backward-compatible API, the latter sets the stage for some potential future where the compiler might typecheck a program, but then abort and not code generate. … seriously, I still don’t see how that future can be. Can someone please give a concrete example of circumstances where that might happen? Ben hints at sub-module granularity, but that slices it orthogonal to the current proposal. He also write

Lumping together all of the recompilation checks into a single hash would expose a relatively ugly facet of GHC's implementation to plugin authors and force authors to tie together logic from conceptually-distinct compilation phases.

but that is also not quite true. Note that the hash is not generated _during_ the passes, but needs to be calculated before. The type signature of the recalculation check, namely pluginRecompile :: [CommandLineOption] -> IfG PluginRecompile clearly indicates that this is a per-module check (otherwise, you’d see an ModGuts input, or such). And even if, in the future, we have ability to provide a finer grained mechanism, we can add the necessary functions _then_ when we know how it looks. Cheers, Joachim Am Montag, den 05.03.2018, 08:57 +0000 schrieb 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 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 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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/