Require -fexternal-interpreter support for future TH changes?

Simon Marlow marlowsd at
Thu Jun 23 09:24:06 UTC 2016

I've answered all these questions (I hope) in the form of new Notes and
signposts, please feel free to comment on this diff:  I'm happy to add more if needs be.

On 22 June 2016 at 16:39, Richard Eisenberg <eir at> wrote:

> On Jun 22, 2016, at 10:38 AM, Simon Marlow <marlowsd at> wrote:
> > Thanks for the feedback Richard.  It's helpful to know which parts of
> the implementation you found non-obvious.  I will write some more Notes,
> but first:
> I think what would help most is a place that describes the little state
> machine that's going on here: the startTH / runTH / finishTH cycle, with
> possible callbacks in between. All RPC calls are blocking, yes? That
> certainly simplifies the matter. In the state machine, I think it would
> help to see clearly what causes the state transition (e.g. splice
> encountered during renaming, reify call made during splicing) and where the
> code is located (both source file/function and client vs server). There's
> just a bunch of moving parts here spread across a number of files and two
> processes.
> >
> > * On why we need a RemoteRef of an IORef - because the IORef lives on
> the server, so GHC has a RemoteRef to it.   Did you see Note [External GHCi
> pointers] in compiler/ghci/GHCi.hs?  Does that help?
> Somewhat. So the server is sending a pointer (the IORef) to the client?
> Presumably this pointer is only usable on the server, so the client just
> ends up sending it back at some point. From the client's point of view,
> it's just getting an opaque key that only the server can decode. Perhaps
> this would all become clearer with the overall map.
> >   Should I xref it from somewhere else?
> Perhaps from libraries/ghci/GHCi/RemoteTypes.hs, on the declaration of
> RemoteRef.
> Thanks!
> Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list