Require -fexternal-interpreter support for future TH changes?

[Simon Marlow]

*Background*

A few months ago I added -fexternal-interpreter to GHC:

   - docs:
   http://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#ghc-flag--fexternal-interpreter
   - 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160622/7c0af58c/attachment.html>