.. and now, my real reason for posting the previous message 8)
Unfortunately, the big limitation of this is that we're going through the FFI to get things to work.
This kinda sucks because that means that the exported functions have to stick to exporting one of the prim_types (Int, Char, Float, Double, Ptr, StablePtr, and a few others).
So, is there some wizardry out there which allows using the RTS Linker to load up .o modules which are not created with the FFI? I've been experimenting with it, and I just get segfaults if I try to load the adder_closure, adder_entry, adder_fast1 or adder_info symbols.
You *should* be able to just get the address of adder_closure and coerce it to the right type. The difficulty with this is that lookupSymbol returns a Ptr, which is an unboxed type, whereas the function type is a boxed type. Coercing unboxed types to boxed types is highly unsafe, because they have different representations on the stack. However, GHCi does exactly this, and coerces from one to the other using addrToHValue# (see ByteCodeLink.lookupCE). It's dangerous, but we'd know pretty quickly if it didn't work. The Right Thing To Do would be to do the communication with the RTS linker in terms of StablePtrs, but there's a performance overhead for doing that (perhaps not too bad, I haven't measured it). Cheers, Simon