<div dir="ltr">I'm not a GHC dev, but I have been following the list. I recently managed to build and run a small game written in Haskell on Android. I am also interested in iOS development. Being able to use Template Haskell inside a cross-compiler would allow me to use Manuel Chakravarty's 'language-c-inline' package which makes heavy use of it.<div><br></div><div>I'm very excited by your work and would be interested in testing any solutions you came up with.<br><div><br></div><div>Sean</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 December 2014 at 01:21, Luite Stegeman <span dir="ltr"><<a href="mailto:stegeman@gmail.com" target="_blank">stegeman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Dec 4, 2014 at 12:07 PM, Simon Peyton Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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).</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>luite</div><div><br></div></font></span></div></div></div>
<br>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>