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

[Joachim Breitner]

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 <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
> > 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180305/03137d56/attachment.sig>