Require -fexternal-interpreter support for future TH changes?

[Simon Marlow]

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

On 22 June 2016 at 16:39, Richard Eisenberg <eir at cis.upenn.edu> wrote:

>
> On Jun 22, 2016, at 10:38 AM, Simon Marlow <marlowsd at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160623/a2c5273f/attachment.html>