<div dir="ltr">just a quick heads-up:<div><br></div><div>After discussing with Thomas at ZuriHac I now have a review-ready patch (and a demo program that uses all the hooks) that should do everything Thomas, Edsko and I need, and is extensible if new things come up. I'm still in Switzerland though, and my internet connection is spotty, I'll try to submit it tonight or tomorrow morning</div>
<div><br></div><div>luite</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 27, 2013 at 6:18 PM, Thomas Schilling <span dir="ltr"><<a href="mailto:nominolo@googlemail.com" target="_blank">nominolo@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think there are a couple of things that are worth exposing. Looking<br>
at Luite's patch, for example, there are a few that a basic high-level<br>
platform wouldn't solve. A few things an API might reasonably want to<br>
customise:<br>
<br>
- Parse custom flags (when wrapping GHC)<br>
<br>
- Hook into GHC's compilation manager or use one-shot mode and use<br>
Shake as a more flexible compilation manager<br>
<br>
- Foreign function calling conventions (e.g., for GHCJS)<br>
<br>
- Compilation ways (can't think of a good example here)<br>
<br>
- The location of built-in / hardcoded identifiers (i.e., the PrelNames stuff)<br>
<br>
- How modules are found (Finder) and where they are stored (e.g.,<br>
network-backed store, in-memory only)<br>
<br>
- Wrap/Adapt various stages of the<br>
renamer/typechecker/optimiser/codegen. Mostly for IDE tools<br>
(including tools to examine compiler transformations), but custom<br>
backends also need to replace the codegen bits<br>
<br>
- Run custom stages in DriverPipeline or adapt existing ones<br>
(including not running them)<br>
<br>
- Both Lambdachine and GHCJS implement a custom code generator. I<br>
think GHCJS is translating from STG. Lambdachine used to start from<br>
CorePrep, but due to the weird "unarise" stuff I had to switch to<br>
using STG which isn't too bad as it also seems more stable. A custom<br>
code generator requires disabling the "Asm" pass and all subsequent<br>
passes from DriverPipeline<br>
<br>
- I'm not so sure about syntactic extensions. They might be better<br>
implemented using haskell-src-exts and then translated into plain<br>
Haskell<br>
<br>
If we can get these things integrated nicely then it would be<br>
worthwhile to wait another year.<br>
<div class="HOEnZb"><div class="h5"><br>
On 27 August 2013 09:17, Simon Peyton-Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>> wrote:<br>
> I’m sympathetic to supporting GHCJS. But, as described in my email, there<br>
> seems to be several different proposals for extending plugins swirling<br>
> around, and I’m not sure how they relate to each other.<br>
><br>
><br>
><br>
> My suggestion (for you guys to lead J):<br>
><br>
> · Identify the minimum necessary for GHCJS in 7.8<br>
><br>
> · Debate the remaining proposals under less time pressure<br>
><br>
><br>
><br>
> Simon<br>
><br>
><br>
><br>
> From: Carter Schonwald [mailto:<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>]<br>
> Sent: 23 August 2013 19:36<br>
> To: Daniel F<br>
> Cc: Simon Peyton-Jones; ghc-devs<br>
> Subject: Re: extending GHC plugins with Hooks<br>
><br>
><br>
><br>
> indeed, ghcjs is one of the things i'm most looking forward to!<br>
><br>
> That the hooks machinery needed to nicely support GHCJS will enable many<br>
> other use cases is also something i'm excited about too... would be a shame<br>
> for neither to work with 7.8 ....<br>
><br>
><br>
><br>
> -Carter<br>
><br>
><br>
><br>
> On Fri, Aug 23, 2013 at 2:09 PM, Daniel F <<a href="mailto:difrumin@gmail.com">difrumin@gmail.com</a>> wrote:<br>
><br>
> Hello<br>
><br>
><br>
><br>
> On Thu, Aug 22, 2013 at 8:13 PM, Simon Peyton-Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>><br>
> wrote:<br>
><br>
> Luite, Edsko, Thomas, Nicolas<br>
><br>
><br>
><br>
> You have all variously proposed improvements to the GHC API and/or the<br>
> plug-in mechanism. I have been so swamped in the last few months that I<br>
> have not had a chance to look carefully at your proposals, nor how they<br>
> relate to each other.<br>
><br>
><br>
><br>
> We are now only three weeks away from wanting to do a feature freeze on GHC<br>
> 7.8, and there are a lot of other things that we want to complete<br>
><br>
> <a href="http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8" target="_blank">http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8</a><br>
><br>
> (Mostly they have gestating for some time.)<br>
><br>
><br>
><br>
> So I’m hoping you’ll be ok with not putting these plugin-related changes<br>
> into 7.8. I have the sense that they’d benefit from more discussion among<br>
> the folk interested in plugins. Perhaps some of the ideas could be combined<br>
> nicely; I don’t know. And the people who are going to write plugins are<br>
> also probably up for building HEAD anyhow.<br>
><br>
><br>
><br>
> (Exception: Luite, I think you have some fairly narrow, specific changes<br>
> that would help GHCJS, and I’m probably fine with those if you care to send<br>
> patches.)<br>
><br>
><br>
><br>
> Does this mean that GHCJS patches will be accepted, but it has to use some<br>
> other mechanism (not Hooks)?<br>
><br>
> It would be really nice to see ghcjs support in the upcoming GHC.<br>
><br>
><br>
><br>
><br>
><br>
><br>
> Please say if you think there’s a really strong reason for putting stuff in<br>
> the 7.8.<br>
><br>
><br>
><br>
> Thanks<br>
><br>
><br>
><br>
> Simon<br>
><br>
><br>
><br>
> From: ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org">ghc-devs-bounces@haskell.org</a>] On Behalf Of Luite<br>
> Stegeman<br>
> Sent: 21 August 2013 03:51<br>
> To: ghc-devs<br>
> Subject: extending GHC plugins with Hooks<br>
><br>
><br>
><br>
> hi all,<br>
><br>
><br>
><br>
> Sorry for taking so long to get back with this. I'm proposing a somewhat<br>
> general way for adding 'hooks' to the GHC API, where users can override<br>
> parts of the default compiling pipeline.<br>
><br>
><br>
><br>
> Hooks are simply functions or actions that replace existing compiler<br>
> functionality. This means that usually only one application can use a<br>
> specific hook at a time.<br>
><br>
><br>
><br>
> The obvious data structure to store the hooks is DynFlags. Unfortunately<br>
> defining hooks in DynFlags directly would give birth to the mother of all<br>
> import cycles, and it would also break the split-dll scheme on Windows. So<br>
> here's the idea:<br>
><br>
><br>
><br>
> - Define each hook in the module where it's exported<br>
><br>
> - For each hook make a 'phantom' DataType and an instance for the Hook type<br>
> familiy<br>
><br>
> - Add a TypeRep based map in DynFlags [0]<br>
><br>
> - For each hooked function, check for existence of a hook in DynFlags,<br>
> otherwise run the default. Example:<br>
> <a href="https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L83" target="_blank">https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L83</a><br>
><br>
><br>
><br>
> Now this approach does have some disadvantages:<br>
><br>
> - No clear integration with existing plugins (I've tried adding an<br>
> onLoadPlugin field to Plugin, where the Plugin could update DynFlags when<br>
> it's loaded, but it was a bit messy, and plugins would not be loaded in time<br>
> for some hooks, particularly what Edsko needs)<br>
><br>
> - More of GHC depends on type families<br>
><br>
> - Decentralized hooks definitions feel a bit messy<br>
><br>
><br>
><br>
> So I'm open to suggestions for improvements (or replacements) of this<br>
> scheme. I have some time the coming weeks to clean up or change the patch.<br>
><br>
><br>
><br>
> We've been testing some hooks with GHCJS for a while, and so far they seem<br>
> to provide what we need (but I'm going to doublecheck the coming weeks that<br>
> we don't have missing functionality):<br>
><br>
><br>
><br>
> - Customizations for linking JavaScript code with our own library locations<br>
> [1]<br>
><br>
> - Hooking into the DriverPipeline so we can use the compilation manager [2]<br>
><br>
> - Desugaring customizations to remove some C-isms from the FFI code [3]<br>
><br>
> - Typechecking foreign import javascript imports [4]<br>
><br>
> - Override the built-in GHC.Prim so we can customize primop types [5]<br>
><br>
><br>
><br>
> I think it's easy to add those for Edsko and Thomas as well.<br>
><br>
><br>
><br>
> luite<br>
><br>
><br>
><br>
> [0]<br>
> <a href="https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L239" target="_blank">https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L239</a><br>
><br>
> [1]<br>
> <a href="https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L44" target="_blank">https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L44</a><br>
><br>
> [2]<br>
> <a href="https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L192" target="_blank">https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L192</a><br>
><br>
> <a href="https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L335" target="_blank">https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L335</a><br>
><br>
> [3] <a href="https://github.com/ghcjs/ghcjs/blob/master/src/Gen2/Foreign.hs#L67" target="_blank">https://github.com/ghcjs/ghcjs/blob/master/src/Gen2/Foreign.hs#L67</a><br>
><br>
> <a href="https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L83" target="_blank">https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L83</a><br>
><br>
> [4] <a href="https://github.com/ghcjs/ghcjs/blob/master/src/Gen2/Foreign.hs#L68" target="_blank">https://github.com/ghcjs/ghcjs/blob/master/src/Gen2/Foreign.hs#L68</a><br>
><br>
> <a href="https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L1374" target="_blank">https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L1374</a><br>
><br>
> [5]<br>
> <a href="https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L191" target="_blank">https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L191</a><br>
><br>
> <a href="https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L239" target="_blank">https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch#L239</a><br>
><br>
><br>
><br>
> (sorry the linked patch also contains other modifications required for<br>
> GHCJS, that i'm going to submit separately)<br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Sincerely yours,<br>
> -- Daniil Frumin<br>
><br>
><br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
><br>
</div></div></blockquote></div><br></div>