Hi Luite, Would we be able to adapt this to get generalized Template Haskell support for GHC iOS/cross compilation?
Cheers Luke On Wed, Sep 4, 2013 at 6:09 PM, Luite Stegeman <stege...@gmail.com> wrote: > 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 > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs