Re: Remote GHCi

I've been thinking of these applications before, in the context of cross compilers, and of how to deal with these things as dependencies. Custom error message formatting could be done in the same way as Template Haskell I think, since there appears to be a reasonably well-defined place where these are needed, and the cost of marshalling the data does not look prohibitive for this application. It could run in the Quasi monad (which would perhaps get some extensions) with type similar to formatError :: Quasi m => TypeError -> m (Maybe Doc) (IDE people will argue that errors shouldn't be formatted as Doc, some structured error message format is needed, we could add that later) Two questions: - Which formatters would be loaded by GHC? Would libraries supply formatters that automatically get loaded by everything that depends on the package? - How would GHC decide which formatter(s) to call for a specific error? As for typechecker (and also core-to-core) plugins: Am I right in thinking that these can usually be treated as a separate build tool, where having it in a separate package is not too problematic? This way, plugins could be loaded from dynamic libraries at startup (or for platforms where this is problematic, GHC could bootstrap itself by linking the plugins statically). Plugins would be built for the host platform, so GHC's package database, which lists packages for the target platform, may not be relevant at all. Cabal would only need to check whether GHC can somehow load pluginpackage-x.y.z before proceeding with the build. I like the idea of extending GHC in various places, but for GHCJS I do need a somewhat workable story for cross-compilation. (Of course I could make GHCJS a non-crosscompiler, by compiling the whole compiler to JS and running everything in a JS runtime; everything would magically work again, but that's a bit too deep down the rabbit-hole for me at the time...) luite Am I right in thinking that typechecker plugins are a special On Tue, Nov 17, 2015 at 2:30 PM Richard Eisenberg wrote:

How does this interact with typechecker plugins? I assume they would still happen in GHC's process.

I've also been thinking about designing and implementing a mechanisms where programmers could specify custom pretty-printers for their types, and GHC would use these pretty-printers in error messages. This action would also probably need to be in the same process.

Would either of these ideas be affected? My guess is "no", because we should be able to be selective in what gets farmed out to the second process and what stays locally.

Richard

On Nov 17, 2015, at 5:10 AM, Simon Marlow 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs