Require -fexternal-interpreter support for future TH changes?

[Simon Marlow]

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 <ezyang at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160622/52956750/attachment.html>