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 <simo...@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-boun...@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@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
