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" <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
