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 <ezy...@mit.edu> wrote: > 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: > > > 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 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs