[Haskell-cafe] Hot-Swap with Haskell

[Evan Laforge]

On Fri, Jul 16, 2010 at 11:21 AM, Don Stewart <dons at galois.com> wrote:
> Generally, in Erlang or Haskell, the semantics we use is to keep
> all the old code in memory, for  the case of closures and thunks that
> point back into that code.
>
> You can imagine a fine-grained semantics where as each top level
> function is no longer referenced, the *code* for that is swapped. I
> believe there have been versions of Erlang bytecode hotswapping that
> supported that.
>
> In GHC Haskell, we have component-level hotswapping -- only
> whole-modules may be swapped out at the moment. As we can't unload code
> based on the GC dropping references, we just keep it all in memory,
> migrating to new code as *new* (dynamic) bindings are introduced.
>
> The type migration issue is yet another problem. There are several
> approaches to migrating state types, including serialization (as xmonad
> et al do), or using open data types.

Is hs-plugins working?  I thought it was bit-rotted and needed
reworking to function with modern ghc?

I'm using the xmonad style static config, but I don't think it's very
practical for a reason Andy didn't mention: linking is slow when a
program gets big, so every little change takes a long time.  xmonad
gets away with it because it's tiny.  I use hint to interpret code
dynamically, but that makes the program even bigger and linking even
longer, so it seems like to have my cake and eat it too I would need
to be able to recompile a single module, and then dynamically link it
into the running application.

In my case, I don't think I need to worry about old closures or code
migration because I would just be loading new functions to splice into
an event loop that can only return data types defined in the main app.
 So it would be acceptable to swap a module by removing all the
functions loaded from it, unloading and reloading the module, and
splicing in the new list of functions it exports.

I'm not sure how I could prove to a dynamic loading system that I'm
holding no references to its code anymore and it can just unload it,
but I suppose it would be the same as a C plugin system: if you return
pointers to plugin code and stash them in the host, you will be in
trouble when the module gets unloaded.  I suppose that just means you
have to rnf all the data coming out of the plugin before you unload
it, right?

Is this the sort of thing hs-plugins can do?

The other thing I thought of was to use xmonad-style static config,
but speed up the link by linking the larger parts dynamically.  Isn't
ghc supposed to support dynamic linking now?  Or would it be just as
slow because the time subtracted from the link phase would simply be
added to the load phase?