GHCi hacking

[pepe]

If you have gone that far and modified ghci, wouldn't it be easier to
disable the :load command and hardwire the loading of the UserLayer
module ?

1) CAFs (Constant Applicative Form) are essentially top level
bindings. Top level bindings are closures, as anything in ghc, and
they are in suspended state until they are evaluated. When this
happens the closure is updated to store the computed value, and
because of this evaluation effectively happens only once.

2) I don't know, but probably you will notice during your experiments

3) Probably no. What happens to top level bindings in the interactive
environment? I think that you lose that environment too after load and
some other commands. An option is to identify and disable all these
commands.

On 18/08/06, Ulf Norell <ulfn at cs.chalmers.se> wrote:
> 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
>