GHCi hacking

[Simon Marlow]

Ulf Norell wrote:

> 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?

others have answered this, but basically a CAF is a top-level non-value. 
Something bound at the top-level that starts life unevaluated.

> 2) What breaks down if you don't revert them?

Well, one reason is that you can get space leaks, because CAFs in modules that 
are unloaded will be retained in the heap.

Another reason, if I recall correctly, is to avoid shooting yourself in the foot 
too badly if you type 'getContents' at the prompt, because that will put stdin 
into the semi-closed state and prevent it from being used again until it is 
reverted.

There may be other reasons, but I don't remember any.  Perhaps the best way to 
find out is just to try it.  Even better would be to run the GHC test suite with 
that change.

If it doesn't seem to break anything really important, we could make it an 
option you can tweak with :set.

Cheers,
	Simon