GHCi hacking

[Simon Peyton-Jones]

I have not followed the details, but you might consider using GHC as a
library.  That gives you all the facilities of GHCi, but as a library
rather than as a separate process.
	http://haskell.org/haskellwiki/GHC/As_a_library

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces at haskell.org
[mailto:glasgow-haskell-users-bounces at haskell.org]
| On Behalf Of Ulf Norell
| Sent: 18 August 2006 10:40
| To: glasgow-haskell-users at haskell.org
| Subject: GHCi hacking
| 
| Hi.
| 
| I want to use GHCi as the interface to my Application. The simple
| solution is to have the Application store its state in global IORefs.
| A user can then start up ghci with -package Application and use the
| provided functions to communicate with the Application. This works
| nicely.
| 
| Now the tricky part. I want the user to be able to implement her own
| layers on top of the Application API. A typical user interaction
| could look something like this:
| 
| $ ghci -package Application
| *Application:API> startApplication
| *Application:API> :load UserLayer
| *main:UserLayer> myCleverFunction 42
| 
| The problem, of course, is that as soon as the user says ':load' ghci
| forgets all about the state of the Application. My solution to the
| problem is to compile my own version of ghci (copy InteractiveUI.hs
| and use -package ghc) and remove the call to rts_revertCAFs when
| loading new modules. This seems to work, but since I don't really
| have a clue what I'm doing I wanted to ask a few questions:
| 
| 1) What is a CAF?
| 2) What breaks down if you don't revert them?
| 3) Does not reverting the CAFs really solve my problem?
| 
| / Ulf
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users