extending GHC plugins with Hooks

Fri Aug 23 20:09:37 CEST 2013

Hello

On Thu, Aug 22, 2013 at 8:13 PM, 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.)****
>
> **
>

Does this mean that GHCJS patches will be accepted, but it has to use some
other mechanism (not Hooks)?

It would be really nice to see ghcjs support in the upcoming GHC.

>  **
>
> 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)****
>
> ** **
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>

-- 
Sincerely yours,
-- Daniil Frumin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130823/f1f511d6/attachment.htm>