Spurious recompilations when using a compiler plugin

Ben Gamari ben at smart-cactus.org
Tue Sep 19 12:59:54 UTC 2017


Conal Elliott <conal at conal.net> writes:

> It appears that use of GHC plugins causes client code to get needlessly
> recompiled. (See Trac issues 12567
> <https://ghc.haskell.org/trac/ghc/ticket/12567> and 7414
> <https://ghc.haskell.org/trac/ghc/ticket/7414>.) It’s becoming more of a
> problem for usability of the plugin
> <http://conal.net/papers/compiling-to-categories> I’ve been developing, and
> I’m wondering what can be done. Some questions:
>
>    - Is there any work in progress on fixing this situation?
>    - Are there serious obstacles to fixing it?
>    - Do plugin writers or users have any workarounds?
>
I think the real question is what sort of interface do plugin authors
need? 

I suspect there are a few distinct tasks here,

 * compute and record module implementation hashes in interface files

 * to include plugin implementation hashes in the recompilation check

 * to provide an interface allowing a plugin to compute a hash of its
   arguments which can be included into the recompilation check. One way
   of realising this would be to add a field like the following to Plugin,

       pluginHash :: [CommandLineOption] -> Maybe Fingerprint
           -- Nothing would denote "always rebuild"

   Would this help in your case?

This would allow us to fix the TH problem in #7277 and fix the plugins
problem in #7414 and #12567 in a nearly optimal way (assuming the plugin
author is able to precisely define a hash).

None of this is terribly difficult and given Nick's recent work on his
row types plugin, it seems like it's getting more urgent.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170919/fc976504/attachment.sig>


More information about the ghc-devs mailing list