Some time ago it was agreed that the typing of `foreign export dynamic' should be changed from prim_type -> IO Addr to prim_type1 -> IO (FunPtr prim_type2) -- where prim_type1 == prim_type2 and deprecating (but keeping) the old typing. While hacking around in GHC's sources to implement this, I came across a few other typing issues. The first one is the typing of `foreign import dynamic', which is documented as Addr -> (prim_args -> IO prim_result) GHC currently implements more or less `Addr -> prim_type', but that's not the point here. I propose changing this to FunPtr prim_type1 -> prim_type2 -- where prim_type1 == prim_type2 again deprecating and keeping the old typing. Apart from the purely technical `IO' (hmmmm, is this *really* necessary?), it makes things almost symmetrical to f.e.d. Another point is the typing of `foreign label', which is currently simply Addr I propose to change this to *two* possible typings: Ptr a FunPtr a because it's not clear if we refer to a data pointer or to a function pointer. This doesn't look particularly nice, or am I missing something here? A last point is the relationship between data type renamings and the FFI: Although we often say that `the FFI looks through newtype' (and `type', of course), it currently only does at certain points, e.g. newtype Foo = Foo Int32 type Bar = Foo -> Word32 foreign import baz :: Bar is allowed, but newtype Blah = Blah (Int32 -> Word32) foreign import booh :: Blah is not. Should we make newtype completely transparent? I'm not sure what this really buys us, but at least it would make the description of the FFI somewhat simpler. I don't have a very strong opinion about this, so I'd like to hear what other people think. Cheers, Sven