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 <e...@cis.upenn.edu
<mailto:e...@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 <marlo...@gmail.com
<mailto:marlo...@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@haskell.org <mailto:ghc-devs@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
