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
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?
I can't really help here. But I'm interested in more powerful ways to extend GHCi, too. I'm mostly interested in things that will speedup development (e.g. Hoogle tab-completion, integration of testing tools). I think once we have a more powerful API to hook things into a running GHCi, people will create useful things that you wouldn't have imagined beforehand. Cheers, Simon
On Tue, Dec 04, 2012 at 04:23:02PM +0100, Dennis Felsing wrote:
Is there a way to extend GHCi without copying some of its source code?
Someone was looking at moving the ghci code into a library, which may mean you need to copy less code, at least. I'm not sure what the status of that is, though.
Is there a chance of having these features flow back into mainline GHCi once they are properly implemented?
Sure, providing the complexity is not disproportionately high for the functionality. Thanks Ian
participants (3)
-
Dennis Felsing -
Ian Lynagh -
Simon Hengel