marlowsd at gmail.com
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
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.
> 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:
> 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?
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
More information about the ghc-devs