Simon & I just uncovered a slight problem with the FFI spec. It is legal to use a newtype as an argument type (Section 3.2, the FFI spec uses the term "renamed datatype" to mean newtype here). It doesn't say whether the newtype has to be in scope non-abstractly or not - indeed the intention seems to be that if the newtype is in scope, abstractly or not, it is legal to use it as an argument type. This is what GHC implements. However, arguably this is wrong. By naming an abstract newtype in a foreign declaration, we can learn something about its implementation: namely whether it is a legal FFI argument type or not. Some abstraction has been lost. Should we require that newtypes used as foreign argument types be non-abstract? This is undesirable - we often don't want to make the actual representation visible, but we nevertheless want the newtype to be a legal foreign argument type (c.f. the CTypes module, which exports a bunch of newtypes abstractly). I can't see a simple solution. Perhaps we just declare that when a newtype is exported abstractly, it's suitability as a foreign argument type is still visible. Cheers, Simon