On Thu, Dec 4, 2014 at 12:07 PM, Simon Peyton Jones
Luite's "out of process TH" work is amazing. If someone had suggested it to me I'd have said "it sounds entirely impractical", but he showed that I would have been quite wrong.
I haven't had much time to actually help Moritz lately, due to other GHC 7.10 patches, the new GHCJS codegen and work to get Cabal support for GHCJS merged. Building/linking the code for the splices can be done in GHC without additional dependencies, and with the recent changes in the template-haskell package (if I haven't missed anything), serialization for communication can also be implemented in a ligthtweight way based on Generic or Data without additional dependencies. I'd like to start simple and treat the Template Haskell runner as an external build tool, possibly installable as a cabal package. GHC would just start a runner process and communicate with it over the standard pipes whenever it needs to run TH. The runner is then responsible for loading and executing the code (in most cases a dynamic library for each splice) on the target. I intend to start by making a patch that adds the runner to the 'settings' file, such that users can enable TH in a stage1 (cross) compiler by pointing GHC to the correct runner program. Other than the minor changes in SysTools (for 'settings'), the code for this would be common to all implementation alternatives. We can then figure out whether this approach is flexible enough and further work out configuration options and serialization protocol, or whether Moritz' idea of loading a plugin to have more control over TH code generation is worth the additional complexity (a different loading mechanism would be required for plugins in cross compilers). luite