Remote GHCi

[Simon Marlow]

Ok, it seems that (1) is easy to support in a remote GHCi, (2) is not, 
and (3) I'm not sure about.

GHCi itself does something very similar to (3): when we compile a 
statement it becomes a value of type IO [HValue], that we can evaluate 
and get back a list of the values that were bound to variables by the 
statement.  In remote GHCi I can support this by having an RPC to 
evaluate the IO action and the returned HValues are remote references 
(StablePtrs) to values in the interpreter context.

In any case I don't plan to break anything unless we have alternative 
ways to support everything without major upheaval.  In the meantime 
there will probably be a flag to select remote GHCi, and existing use 
cases will continue to be supported.

Cheers
Simon

On 17/11/2015 17:11, Andrew Gibiansky wrote:
> Simon,
>
> As Sumit said, we use dynCompileExpr for core functionality of IHaskell.
> I am not really sure how the change you are proposing affects that, though.
>
> We use dynCompileExpr in several places for evaluation inside the
> interpreter context:
>
> 1. Evaluating a Haskell expression in the interpreter context,
> converting the result to a ByteString, then using fromDynamic to extract
> the bytestring and convert it to a value in the compiled context.
> 2. Getting a file handle from the interpreter context to the compiled
> context; this does not actually use dynCompileExpr because there were
> some bugs with dynCompileExpr and so I had to literally copy source from
> InteractiveEval to reimplement parts of dynCompileExpr (unrelated: the
> issue was that dyncompileexpr imported and then unimported Data.Dynamic,
> and this messed with data declarations that had already been created in
> the interpreter context)
> 3. Extracting IO a values from the interpreted context to the compiled
> context so that they could be run; this is necessary to get displayed
> values from the interpreter back to the compiled code.
>
> I think two of our uses, which are both very central to the way IHaskell
> works, would be impacted by requiring a Binary instance (or similar),
> which is what I think you are proposing (since we have two uses at least
> where we marshall `IO x` values via dynCompileExpr, which cannot be
> serialized, I believe.)
>
> I am sure that there are alternative ways to do what we are doing, but
> they are probably not simple and would take quite a bit of work.
>
> -- Andrew
>
> On Tue, Nov 17, 2015 at 6:29 AM, Richard Eisenberg <eir at cis.upenn.edu
> <mailto:eir at cis.upenn.edu>> wrote:
>
>     How does this interact with typechecker plugins? I assume they would
>     still happen in GHC's process.
>
>     I've also been thinking about designing and implementing a
>     mechanisms where programmers could specify custom pretty-printers
>     for their types, and GHC would use these pretty-printers in error
>     messages. This action would also probably need to be in the same
>     process.
>
>     Would either of these ideas be affected? My guess is "no", because
>     we should be able to be selective in what gets farmed out to the
>     second process and what stays locally.
>
>     Richard
>
>     On Nov 17, 2015, at 5: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
>      > _______________________________________________
>      > ghc-devs mailing list
>      > ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>      > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>