Remote GHCi

[Simon Marlow]

So the remote GHCi server I had in mind would be too dumb to support 
this - it would be at a much lower level, with support for linking 
object code and bytecode and evaluation only.  What you probably want 
for this is a remote interface to the GHC API, similar to what 
ide-backend provides.

Cheers,
Simon

On 17/11/2015 10:40, Alan & Kim Zimmerman wrote:
> This fits in directly with what I am trying to do for the
> haskell-ide-engine, where the intention is to expose ghci via an
> asynchronous process with communication via message passing.
>
> A bonus would be to have two separate interfaces, one for REPL
> interaction for the user, the other to be able to query properties of
> the loaded code.
>
> I am currently investigating exposing Behavior and RunTerm from
> haskeline to create a message passing backend instead.
>
> Alan
>
> On 17 Nov 2015 12:11 PM, "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
>