Remote GHCi

Simon Marlow marlowsd at
Fri Jan 8 08:42:45 UTC 2016

Yes, I used the GHCJS code as a starting point for Remote GHCi - the 
implementation of TH in Remote GHCi is very similar to GHCJS.  Luite and 
I have chatted about this in person, and I believe he intends to try to 
merge them at some point.

Remote GHCi should make it possible to do TH with a cross-compiler, 
though you still need to be able to run code on the target platform at 
compile-time, like GHCJS does with nodejs.


On 08/01/2016 07:18, Moritz Angermann wrote:
> I’m not sure how much I can actually contribute to this, but I’ll just add a
> few pointers to nothing gets lost.  I’m not very familiar with remote ghci, but I
> think that there is some overlap between remote ghci and out of process template
> haskell compilation[1][2].  Most of ghcjs’s TH code is in src/Gen2/TH.hs.
> To be honest, I haven’t had much time last year to do anything for the out of
> process th stuff.  I’m planing to get back at oopth, once we got shaking-up-ghc[3]
> to build cross compilers properly. From the looks of it, that could be soon :)
> I only know about the ghcjs repl[4] through twitter. I’m certain luite can share a
> lot more here.
> With respect to remote ghci, I haven’t had much time to look into it. The main focus
> of out of process th (for me) was getting TH to work for cross compiler, which means
> shipping code to a remote process through some kind of channel that the remote allows*.
> Hope this might help in some way.
> Cheers,
> Moritz
> [1]:
> [2]:
> [3]:
> [4]:
> [*]: E.g. getting this to work for iOS.
>> On Jan 8, 2016, at 2:01 PM, Edward Z. Yang <ezyang at> wrote:
>> I was reviewing some history here, and I realized
>> that the GHCJS folks had previous implemented this:
>> What ever happened to this line of work?  Does remote GHCi
>> subsume it?
>> Edward
>> Excerpts from Simon Marlow's message of 2015-11-17 02:10:55 -0800:
>>> Hi folks - I've been thinking about changing the way we run interpreted
>>> code so that it would be run in a separate process.  It turns out this
>>> has quite a few benefits, and would let us kill some of the really
>>> awkward hacks we have in GHC to work around problems that arise because
>>> we're running interpreted code and the compiler on the same runtime.
>>> I summarised the idea here:
>>> I'd be interested to hear if anyone has any thoughts around this,
>>> particularly if doing this would make your life difficult in some way.
>>> Are people relying on dynCompileExpr for anything?
>>> Cheers,
>>> Simon

More information about the ghc-devs mailing list