Remote GHCi

[Luite Stegeman]

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 <eir at cis.upenn.edu> 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 <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:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20151117/2c7b6baf/attachment-0001.html>