Remote GHCi

[Simon Marlow]

CC Daniel Corin, maintainer of hint.

On 17/11/2015 11:49, Luite Stegeman wrote:
> 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?

I don't think that simplifies the problem, we would still be dynamically 
loading and running code in the current process, which is exactly what 
we do now.

The issue is with

   interpret :: (MonadInterpreter m, Typeable a) => String -> a -> m a

which would need to become

  interpret :: (MonadInterpreter m, Typeable a, Binary a) => String -> a 
-> m a

or else we have to keep the current single-process mechanism for this 
use case.

Cheers,
Simon



> luite
>
> On Tue, Nov 17, 2015 at 10:10 AM Simon Marlow <marlowsd at gmail.com
> <mailto: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
>