Remote GHCi

[Andrew Gibiansky]

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>
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> 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
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151117/8b8489ea/attachment-0001.html>