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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
