Out Of Process Template Haskell

[Sean Seefried]

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.

Sean

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>