Remote GHCi

Simon Marlow marlowsd at
Tue Nov 17 11:08:07 UTC 2015

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.


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
> <mailto:marlowsd at>> 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:
>     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 <mailto:ghc-devs at>

More information about the ghc-devs mailing list