On Fri, Jul 16, 2010 at 11:21 AM, Don Stewart
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?