Remote GHCi

[Manuel M T Chakravarty]

Hi Simon,

While this is an interesting proposal, Haskell for Mac strongly relies on running interpreted code in the same process. I’m using ’dynCompileExpr’ as well as ’hscStmtWithLocation’ and some other stuff. This is quite crucial for some of the interactive functionality. Imagine a game where the game engine is in Swift linked into the main application and the game logic is in *interpreted* Haskell code. The engine calls into the Haskell code multiple times per frame of the animation and for all keyboard/mouse/etc input (using StablePtr and ForeignPtr to construct the scene graph across the Swift and Haskell heap).

This is an intricate dance (e.g, exceptions in either language don’t play nice across the language boundary and using multi-threading in both worlds adds to the fun), but it allows for a very nice interactive and responsive user experience.

I actually also might have a use for the architecture that you are proposing. However, I really would like to keep the ability to, at least, optionally run interpreted code in the same process (without profiling etc). Do you think we could have both?

Cheers,
Manuel

> Simon Marlow <marlowsd at gmail.com>:
> 
> 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
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs