Out Of Process Template Haskell

Sean Seefried sean.seefried at gmail.com
Thu Dec 4 23:42:14 UTC 2014

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.

I'm very excited by your work and would be interested in testing any
solutions you came up with.


On 5 December 2014 at 01:21, Luite Stegeman <stegeman at gmail.com> wrote:

> On Thu, Dec 4, 2014 at 12:07 PM, Simon Peyton Jones <simonpj at microsoft.com
> > wrote:
>> 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
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141205/eec418e7/attachment-0001.html>

More information about the ghc-devs mailing list