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#Ret... 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