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?
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs