Spurious recompilations when using a compiler plugin
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 487 bytes
Desc: not available
More information about the ghc-devs