Remote GHCi

[Luite Stegeman]

I like this idea, and it overlaps very much with the work that still needs
to be done for GHCJSi. I think that for Template Haskell, the restriction
that everything has to be marshalled via Binary is not too problematic,
although it'd require a bit of care if Richard's pre-proposal to expose
more GHC types to TH ( #11081 ) is to be implemented. In particular, the
API for querying the type environment would have to remain implementable
via message passing, so we can't expose the full TcRn there.

compileExpr / dynCompileExpr seem to get some use, perhaps mostly through
the hint package:

http://packdeps.haskellers.com/reverse/hint

But I think the most common use case is just compiling and running Haskell
expressions, without any specific need for interpreted code. The machinery
behind hint could be reworked to have the GHC API produce a dynamic library
for the compiled expression, which could then be loaded into the current
process with the system linker. Or is there some reason that  this approach
would be unusable?

luite

On Tue, Nov 17, 2015 at 10:10 AM Simon Marlow <marlowsd at gmail.com> wrote:

> Hi folks - I've been thinking about changing the way we run interpreted
> code so that it would be run in a separate process.  It turns out this
> has quite a few benefits, and would let us kill some of the really
> awkward hacks we have in GHC to work around problems that arise because
> we're running interpreted code and the compiler on the same runtime.
>
> I summarised the idea here:
> https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi
>
> I'd be interested to hear if anyone has any thoughts around this,
> particularly if doing this would make your life difficult in some way.
> Are people relying on dynCompileExpr for anything?
>
> Cheers,
> Simon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151117/9860e644/attachment.html>