#84 GHCi problems

needs test case
Eric Kow

I confess I don't really understand what the bug is, but I know vaguely from the mailing list (mostly Conal) that there's some sort of GHCi-related bug.

See this Haskell-Cafe thread

Not filing this for the upcoming release so much as something we want to keep aware of.

Here's what Jeremy had to say about it:


When I last looked at the problem, the issue was that wxWidgets libraries use static constructors and destructors in some places.

Problem with static constructors is that they typically run before main() - or its equivalent - is called. This means that once you quit an application, there is no way to restart without relaunching executable.

Similarly, static destructors only run after app has called exit().

There were a couple of approaches I considered:

  • Implement a wrapper which forces dynamic load and unload of the wxWidgets libraries from inside wxc. This would work because when reloading the libraries (as you would when restarting app at GHCi), the static constructors run (e.g. in Windows they usually run just before DllMain() is called). This is easy, but very tedious to do in practice, and would only really make sense if the wxWidgets bindings are auto-generated.

  • Fake application exit when running in GHCi so that when app starts again the same event loop is used, and the static destructors are never called. This would be a very neat solution, but state management is very tricky.


  • Eric Kow
    Eric Kow

    Two things I forgot. Here's the symptom Conal reports: “the second time I open a top-level window, the host process (GHCi) dies abruptly”

    (could have sworn we had something on the tracker about this).

    Speculation on the mailing list (Henk-Jan): “Shouldn't GHCi support be all right with the next GHC release? Did someone try a nightly build of GHC to test this? There are no nightly builds for Windows, and I can't get GHC compiled, so I cannot test this.”

    Does next GHC release refer to 7.8 here?