Heap representation evil

[Brandon Moore]

Thinking to take advantage of fortuitous heap layout of some Haskell 
values for interfacing with C, I've written the following function:

addressOf :: a -> Ptr ()
addressOf x = x `seq` unsafeCoerce# (Box x)
data Box x = Box x

For example,

data A = A {-# UNPACK #-} !(Ptr Word8) {-# UNPACK #-} !CInt

main = let a = A nullPtr 12
           p = addressOf a `plusPtr` 4
     in do x <- peek p :: IO Int
           y <- peek p :: IO Int
           print (x, y)
prints
(0, 12)

One thing I don't understand is that this fails if I use Just
rather than inventing my box type. I suppose the info table for
Just is set up to support a vectored return for pattern matching
on Maybe? (the commentary isn't very clear here. The section
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution#ReturnConvention
says, in full:
"Return Convention
 Direct Returns
 Vectored Returns"
)

The reason I'm messing about with this stuff is that I'm pretty sure 
passing p to C code would give a usable pointer to
struct a {char *; int;};

Obviously my plot will be spoiled if the GC comes along and relocates 
the value while C code is trying to use it.

Are there any other pitfalls with this approach?

A different and in all likelihood saner approach is building up more 
tools for manipulating pointers to C data from Haskell, perhaps along 
the lines of cmucl's support for "Alien Objects".
http://www.math.sunysb.edu/~sorin/online-docs/cmucl/aliens.html

The main reason to even think about touching the heap representation of 
Haskell objects is so that the values can be manipulated by pure code,
pattern matched, etc.

Brandon