<div dir="ltr"><div><div><div>Yes - I wasn't planning on dropping support for the in-process interpreter, for that reason.<br><br></div>I haven't thought about plugins very much, but aren't they always compiled code?  We don't need an in-process interpreter for those, but we do need in-process linking.  Maybe that doesn't simplify things much.<br><br></div>Cheers<br></div>Simon<br><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 22 June 2016 at 15:40, Edward Z. Yang <span dir="ltr"><<a href="mailto:ezyang@mit.edu" target="_blank">ezyang@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Simon,<br>
<br>
I have no exception to having it be default and dropping the special<br>
case support for building profiled/dynamic so that TH works.  But<br>
I don't think support for loading code in-process for GHC should be dropped,<br>
c.f. Manuel's email<br>
<a href="https://mail.haskell.org/pipermail/ghc-devs/2015-November/010491.html" rel="noreferrer" target="_blank">https://mail.haskell.org/pipermail/ghc-devs/2015-November/010491.html</a><br>
and also the necessity to run code in-process for typechecking plugins,<br>
etc.<br>
<br>
Edward<br>
<br>
Excerpts from Simon Marlow's message of 2016-06-22 04:51:12 -0400:<br>
> *Background*<br>
<span class="">><br>
> A few months ago I added -fexternal-interpreter to GHC:<br>
><br>
</span>>    - docs:<br>
>    <a href="http://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#ghc-flag--fexternal-interpreter" rel="noreferrer" target="_blank">http://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#ghc-flag--fexternal-interpreter</a><br>
>    - wiki, rationale: <a href="https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi</a><br>
<span class="">><br>
> When -fexternal-interpreter is used, GHC runs interpreted code in a<br>
> separate subprocess, and communicates with it using binary messages over a<br>
> pipe.<br>
><br>
> -fexternal-interpreter currently implements all of TH, quasi-quoting,<br>
> annotations, and all the GHCi features except for some features of the<br>
> debugger.  It is also now implemented on Windows, thanks to Tamar Christina.<br>
><br>
</span>> *Proposal*<br>
<span class="">><br>
> I'd like to propose that going forward we commit to maintaining full<br>
> support for -fexternal-interpreter, with a view to making it the default.<br>
><br>
> Why?<br>
><br>
</span>>    - -fexternal-interpreter will be a prerequisite for GHCJS support, so<br>
<span class="">>    maintaining full support for TH in -fexternal-interpreter will ensure that<br>
>    everything that works with GHC works with GHCJS.<br>
</span>>    - We will be able to make simplifications in GHC and the build system<br>
<span class="">>    once -fexternal-interpreter is the default, because when compiling with<br>
>    -prof or -dynamic we won't have to compile things twice any more.<br>
</span>>    - Ultimately we don't want to have two ways of doing everything, because<br>
<span class="">>    that's harder to maintain.<br>
><br>
> How?<br>
><br>
</span>>    - I'll make all the TH and quasi-quoting tests run with and without<br>
<span class="">>    -fexternal-interpreter, so it will break validate if one of these fails.<br>
><br>
</span>> *Why now?*<br>
<div class="HOEnZb"><div class="h5">><br>
> There are some TH changes in the pipeline that will need special attention<br>
> to work with -fexternal-interpreter.  e.g.<br>
> <a href="https://phabricator.haskell.org/D2286" rel="noreferrer" target="_blank">https://phabricator.haskell.org/D2286</a> and<br>
> <a href="https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective</a>, so I'd<br>
> like to raise it now so we can keep the issue in mind.<br>
><br>
><br>
> Cheers<br>
><br>
> Simon<br>
</div></div></blockquote></div><br></div></div></div></div></div></div>