I've updated the wiki page, expanding the descriptions and adding code from the actual implementation: http://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks An demo program that uses all hooks here: https://gist.github.com/luite/6444273 (I've listed the users (or proposers) of every hook, and how they use it, Thomas / Edsko, can you check that they indeed do what you need?) The patch is here: https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-hooks.patch
In addition to defining the heterogeneous map and the hooks themselves, extra exports have been added to make it possible for users to actually make a hook implementation without copying most of the module's source code. The demo program implements all hooks to check this. Also the GHCJS patch is here: https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.patch It adds the following: - in DynFlags an extra WayCustom constructor to add a custom 'tag' to generated files (GHCJS builds multiple architectures to support Template Haskell among other things, one with the 'js' tag) - in ForeignCall the JavaScriptCallConv calling convention - in Platform an ArchJavaScript architecture - `foreign import javascript' support in the parser and lexer - The JavaScriptFFI extension that enables the `foreign import javascript' syntax, only supported on ArchJavaScript (So using it on a regular GHC would always result in a compile error saying that it's unsupported on the user's platform) luite On Thu, Sep 5, 2013 at 12:17 AM, Thomas Schilling <nomin...@googlemail.com>wrote: > I started a wiki page at: http://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks > > Luite: could you please fill in the hooks that your latest patch defines? > > > On 4 Sep 2013, at 19:40, Simon Peyton-Jones <simo...@microsoft.com> wrote: > > > I do need more than a patch, please, please. A wiki page explaining the > design, as seen by the user (of the GHC API), the problems it solves, and > the use-cases it enables, would be most helpful. > > > > Simon > > > > | -----Original Message----- > > | From: Thomas Schilling [mailto:nomin...@googlemail.com] > > | Sent: 04 September 2013 17:26 > > | To: Simon Peyton-Jones; Luite Stegeman > > | Cc: Nicolas Frisby; "Pedro Magalhães (drei...@gmail.com)"; Richard > > | Eisenberg (e...@cis.upenn.edu); Geoffrey Mainland > > | (mainl...@cs.drexel.edu); Iavor Diatchki; Austin Seipp; Edsko de > Vries; > > | Ryan Newton (rrnew...@gmail.com); David Luposchainsky; ghc- > > | d...@haskell.org > > | Subject: Re: GHC 7.8 release status > > | > > | > > | On 4 Sep 2013, at 15:52, Simon Peyton-Jones <simo...@microsoft.com> > > | wrote: > > | > > | > Edsko/Thomas/Luite: if you want anything for 7.8 it'll have to be > > | jolly soon. At the moment I don't even know the motivation or design, > > | let alone implementation. Could you make a wiki page explaining the > > | proposed design? Is it really important to do this for 7.8? > > | > > | Yes, it is quite important to get this into 7.8. Not having these > > | features in GHC makes it very difficult for people to adopt GHCJS. One > > | could argue that GHCJS is not yet production-ready anyway and users > that > > | want to try it can figure out building GHC from source to use it, but > > | this doesn't quite apply. > > | > > | 1. GHCJS targets a wider audience than users brave enough to compile > > | GHC from source. In addition, the next chance to get these features > into > > | GHC is in a year from now, so when GHCJS becomes more mature then this > > | will be a major hurdle for adoption. > > | > > | 2. These changes are also required for IDE tools which really mustn't > > | require users to build a custom version of GHC. > > | > > | > > | Luite's design is actually very flexible. It simply allows GHC API > > | users to provide functions that are called instead of (or in addition > > | to) existing functions in GHC. Instead of calling, say, "genHardCode", > > | the driver now looks up whether the user has specified a hook for > > | genHardCode and calls that instead. > > | > > | Currently we only specify a small number of hooks that are sufficient > > | for our use cases. Future releases of GHC can be extended to include > > | more hooks, if that is needed. > > | > > | Hooks are stored as an untyped map inside the DynFlags (to avoid issues > > | with circular dependencies). Each hook is looked up using a single- > > | constructor type and type families are used to make this type safe. > > | There is one use of unsafeCoerce to avoid having to make every hook > > | function an instance of Typeable. > > | > > | Unlike CorePlugins, it is only a GHC API feature, and users cannot > > | specify plugins to be added via command line options. If we can come > up > > | with a good design, then we could add this in GHC 7.10, but it is not > > | necessary at this point. > > | > > | Luite: Do you have a link to your latest patch? > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs