Changes between Version 7 and Version 8 of ForeignFunctionInterface

Apr 15, 2006 7:59:54 PM (10 years ago)


  • ForeignFunctionInterface

    v7 v8  
    2828 2. Consider `foreign import "dynamic" foo :: (Int -> IO Int) -> ...`.  Sect 3.2 should make it clear whether `(Int -> IO Int)` is considered a "marshallable foreign type".
    2929 3. I also found the separation of 4.1.3 from 3.2 quite hard to understand. I was searching in 3.2 for "wrapper" and "dynamic" in vain!  I don't have a good solution to this, except perhaps some explicit fwd refs, and a clear explanation of the logic behind the structure of the document.
     30 4. 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.
     32 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.
     34 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).
     36 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.
    3138=== `unsafePerformIO` ===