Require -fexternal-interpreter support for future TH changes?

Simon Marlow marlowsd at
Wed Jun 22 08:51:12 UTC 2016


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

   - docs:
   - wiki, rationale:

When -fexternal-interpreter is used, GHC runs interpreted code in a
separate subprocess, and communicates with it using binary messages over a

-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.


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.


   - -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.


   - 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. and, so I'd
like to raise it now so we can keep the issue in mind.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list