Extending GHCi

[Dennis Felsing]

Hi!

I'm currently trying to extend ghc-vis[1], a tool to visualize live data
structures in GHCi and GHC compiled programs, similar to GHCi's :print and
vacuum.

I want to show the type of a subexpression visualized in ghc-vis. As types
aren't stored in GHC they have to be reconstructed. For this I need read access
to internal GHC(i) information, like the type of data constructors. Type
reconstruction is already happening inside GHCi's debugger[2].

Another concern is having a feature for binding a subexpression to a GHCi
variable, so that it appears in ":show bindings" and can be used within the
current GHCi session.

To me it seems like neither is currently possible from a program running within
GHCi. Therefore I just started an extensible GHCi, called eGHCi[3]. So far it
should compile on GHC 7.4.2 and 7.6.1, but does nothing else than the regular
GHCi. I took the relevant files to compile my own GHCi binary from the
corresponding GHC versions, just as ghci-haskeline[4] did before.

In order to get type reconstruction and bindings running I'm planning to
provide a function

> runInGhci :: GhciMonad a -> IO a

which enables programs running in eGHCi to run commands inside the GhciMonad.

Another change I'm planning is a function

> setupHandler :: Event -> GhciMonad a -> IO ()

which sets an event handler up to be called whenever the specified event
occurs. For now the only event I would need is PostEvaluation, which is evoked
after an evaluation occured. I want to use this to update the view of ghc-vis
automatically after the user entered a new command on the GHCi command line.

My first thought was to define new GHCi commands (like :def) instead of
functions, but then only the user could use them, and not the programs running
inside of GHCi.

Now I'm wondering whether the approaches I have in mind are sensible or if
anyone can think of a better way to achieve my goals? Is there a way to extend
GHCi without copying some of its source code? Is there a chance of having these
features flow back into mainline GHCi once they are properly implemented?

Thanks,
Dennis Felsing

[1] http://felsin9.de/nnis/ghc-vis
[2] http://hackage.haskell.org/trac/ghc/wiki/GhciDebugger#TypeReconstruction
[3] git clone git://r0q.ath.cx/eghci
[4] http://hackage.haskell.org/package/ghci-haskeline