RE: extending GHC plugins with Hooks

OK, that's fine. Thanks! Simon From: Nicolas Frisby [mailto:nicolas.frisby@gmail.com] Sent: 10 September 2013 19:18 To: Simon Peyton-Jones Cc: Luite Stegeman; Edsko de Vries; Thomas Schilling; ghc-devs Subject: Re: extending GHC plugins with Hooks My patch was extremely simple, so I'm asking for forgiveness instead of permission! https://github.com/ghc/ghc/commit/850490af1df426b306d898381a358a35425d16c7 The commit note includes a brief explanation of the benefits. The motivation originates with the HERMIT project at Univ. of Kansas: we'd like to help the user generate new top-level declarations in a module (eg a new datatype). Re-using the type-checker seems the simplest path towards robustness and feature completeness and this patch removes a simple but onerous obstacle. Is this OK? On Thu, Aug 22, 2013 at 11:13 AM, Simon Peyton-Jones mailto:simonpj@microsoft.com> wrote: Luite, Edsko, Thomas, Nicolas You have all variously proposed improvements to the GHC API and/or the plug-in mechanism. I have been so swamped in the last few months that I have not had a chance to look carefully at your proposals, nor how they relate to each other. We are now only three weeks away from wanting to do a feature freeze on GHC 7.8, and there are a lot of other things that we want to complete http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 (Mostly they have gestating for some time.) So I'm hoping you'll be ok with not putting these plugin-related changes into 7.8. I have the sense that they'd benefit from more discussion among the folk interested in plugins. Perhaps some of the ideas could be combined nicely; I don't know. And the people who are going to write plugins are also probably up for building HEAD anyhow. (Exception: Luite, I think you have some fairly narrow, specific changes that would help GHCJS, and I'm probably fine with those if you care to send patches.) Please say if you think there's a really strong reason for putting stuff in the 7.8. Thanks Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.orgmailto:ghc-devs-bounces@haskell.org] On Behalf Of Luite Stegeman Sent: 21 August 2013 03:51 To: ghc-devs Subject: extending GHC plugins with Hooks hi all, Sorry for taking so long to get back with this. I'm proposing a somewhat general way for adding 'hooks' to the GHC API, where users can override parts of the default compiling pipeline. Hooks are simply functions or actions that replace existing compiler functionality. This means that usually only one application can use a specific hook at a time. The obvious data structure to store the hooks is DynFlags. Unfortunately defining hooks in DynFlags directly would give birth to the mother of all import cycles, and it would also break the split-dll scheme on Windows. So here's the idea: - Define each hook in the module where it's exported - For each hook make a 'phantom' DataType and an instance for the Hook type familiy - Add a TypeRep based map in DynFlags [0] - For each hooked function, check for existence of a hook in DynFlags, otherwise run the default. Example: https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patc... Now this approach does have some disadvantages: - No clear integration with existing plugins (I've tried adding an onLoadPlugin field to Plugin, where the Plugin could update DynFlags when it's loaded, but it was a bit messy, and plugins would not be loaded in time for some hooks, particularly what Edsko needs) - More of GHC depends on type families - Decentralized hooks definitions feel a bit messy So I'm open to suggestions for improvements (or replacements) of this scheme. I have some time the coming weeks to clean up or change the patch. We've been testing some hooks with GHCJS for a while, and so far they seem to provide what we need (but I'm going to doublecheck the coming weeks that we don't have missing functionality): - Customizations for linking JavaScript code with our own library locations [1] - Hooking into the DriverPipeline so we can use the compilation manager [2] - Desugaring customizations to remove some C-isms from the FFI code [3] - Typechecking foreign import javascript imports [4] - Override the built-in GHC.Prim so we can customize primop types [5] I think it's easy to add those for Edsko and Thomas as well. luite [0] https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patc... [1] https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L44 [2] https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L192 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patc... [3] https://github.com/ghcjs/ghcjs/blob/master/src/Gen2/Foreign.hs#L67 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patc... [4] https://github.com/ghcjs/ghcjs/blob/master/src/Gen2/Foreign.hs#L68 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patc... [5] https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L191 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patc... (sorry the linked patch also contains other modifications required for GHCJS, that i'm going to submit separately)