extending GHC plugins with Hooks

Tue Sep 10 18:18:26 UTC 2013

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
<simonpj at 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 at 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.patch#L83
> ****
>
> ** **
>
> 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.patch#L239
> ****
>
> [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.patch#L335
> ****
>
> [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.patch#L83
> ****
>
> [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.patch#L1374
> ****
>
> [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.patch#L239
> ****
>
> ** **
>
> (sorry the linked patch also contains other modifications required for
> GHCJS, that i'm going to submit separately)****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130910/ff4d2332/attachment.htm>