Yes - I wasn't planning on dropping support for the in-process interpreter,
for that reason.
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.
Cheers
Simon
On 22 June 2016 at 15:40, Edward Z. Yang
Hello Simon,
I have no exception to having it be default and dropping the special case support for building profiled/dynamic so that TH works. But I don't think support for loading code in-process for GHC should be dropped, c.f. Manuel's email https://mail.haskell.org/pipermail/ghc-devs/2015-November/010491.html and also the necessity to run code in-process for typechecking plugins, etc.
Edward
Excerpts from Simon Marlow's message of 2016-06-22 04:51:12 -0400:
*Background*
A few months ago I added -fexternal-interpreter to GHC:
- docs:
- wiki, rationale: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi
When -fexternal-interpreter is used, GHC runs interpreted code in a separate subprocess, and communicates with it using binary messages over a pipe.
-fexternal-interpreter currently implements all of TH, quasi-quoting, annotations, and all the GHCi features except for some features of the debugger. It is also now implemented on Windows, thanks to Tamar Christina.
*Proposal*
I'd like to propose that going forward we commit to maintaining full support for -fexternal-interpreter, with a view to making it the default.
Why?
- -fexternal-interpreter will be a prerequisite for GHCJS support, so maintaining full support for TH in -fexternal-interpreter will ensure
http://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#ghc... that
everything that works with GHC works with GHCJS. - We will be able to make simplifications in GHC and the build system once -fexternal-interpreter is the default, because when compiling with -prof or -dynamic we won't have to compile things twice any more. - Ultimately we don't want to have two ways of doing everything, because that's harder to maintain.
How?
- I'll make all the TH and quasi-quoting tests run with and without -fexternal-interpreter, so it will break validate if one of these fails.
*Why now?*
There are some TH changes in the pipeline that will need special attention to work with -fexternal-interpreter. e.g. https://phabricator.haskell.org/D2286 and https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective, so I'd like to raise it now so we can keep the issue in mind.
Cheers
Simon