<div dir="ltr"><div>The use-case which I've worked on deals with widget messages. Widgets are stored inside the kernel, and can recieve signals from user code, frontend events etc.</div><div><br></div><div>To capture messages sent by the user code, the messages are queued in a TChan inside the interpreter environment. Messages from this TChan are extracted into the kernel using dynCompileExpr and fromDynamic, and processed as required.</div><div><br></div><div>The user input code is executed in the interpreter context, but we also need to gather information some more information from the context, which is why dynCompileExpr is crucial there.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 November 2015 at 19:59, Richard Eisenberg <span dir="ltr"><<a href="mailto:eir@cis.upenn.edu" target="_blank">eir@cis.upenn.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">How does this interact with typechecker plugins? I assume they would still happen in GHC's process.<br>
<br>
I've also been thinking about designing and implementing a mechanisms where programmers could specify custom pretty-printers for their types, and GHC would use these pretty-printers in error messages. This action would also probably need to be in the same process.<br>
<br>
Would either of these ideas be affected? My guess is "no", because we should be able to be selective in what gets farmed out to the second process and what stays locally.<br>
<span class="HOEnZb"><font color="#888888"><br>
Richard<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Nov 17, 2015, at 5:10 AM, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br>
<br>
> 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.<br>
><br>
> I summarised the idea here: <a href="https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi</a><br>
><br>
> 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?<br>
><br>
> Cheers,<br>
> Simon<br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div>Regards</div><div dir="ltr"><div><br></div><div>Sumit Sahrawat</div></div></div></div></div></div></div>
</div>