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
