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

[Joachim Breitner]

Hi Ben,

thanks for kicking this off.

Am Montag, den 19.02.2018, 22:04 -0500 schrieb Ben Gamari:
> 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.

How realistic is it to do the partial module recompilation thing that
warrants multiple PluginRecompile values per module? For this to be
useful the compiler would have to

 * calculate the typechecker plugin’s hash for module M
 * notice that it has changed, and start compiling M
 * but then, when we have core, magically notice that the output of the
   desugarer has not changed, and consider to abort calculation
 * but then notice that a core2core plugin was involved, and ask that 
   for the new hash
 * and then this hash must be unchanged
 * and then really the compilation has ended.

Is that realistic? Can someone fill this example with concrete life?

Maybe I am just not seeing what people have in mind – but I feel unless
this really is more than a very vague idea, we should consider the
simpler variant where each plugin gets to calculate a single hash per
module – and not possibly many in various stages.

Another way of putting it: The compiler pipeline is (simplified)

 1. decide what to compiler
 2. parse
 3. typecheck
 4. desguar
 5. optimize
 6. code gen

Plugins so far hook into step 3 and 5. Every one of these steps
probably eventually deserves a plugin hook. This proposal is about
adding one to step 1. With this view, I find the “add a single function
to Plugin”, as described in
https://github.com/ghc-proposals/ghc-proposals/pull/108#issuecomment-362671438
much more convincing.

Cheers,
Joachim


-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de
  https://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/20180219/7bd974c1/attachment.sig>