Changes between Version 11 and Version 12 of ForeignFunctionInterface

Oct 9, 2009 11:10:58 AM (8 years ago)


  • ForeignFunctionInterface

    v11 v12  
    1818 * Inappropriate use can subvert all semantic guarantees provided by Haskell and can cause memory corruption and program crashes.
    2023== Open Questions ==
     25The following topics still require a bit of discussion or a decision between multiple alternatives.
     27=== Libraries ===
     29A large part of the FFI addendum are the libraries living under `Foreign` in the library hierarchy.  Given the general discussion surrounding the inclusion of libraries into Haskell', we need a concrete approach for the `Foreign` libraries.  A tentative proposal was the following:
     31 * The FFI addendum has been written before the proposal for HierarchicalModules, it uses a flat names space.  In Haskell', we will use the hierarchical names from the [ standard library.]
     32 * Haskell' keeps a subset of the libraries defined by Haskell 98 (but with their hierarchical names) and adds the FFI libraries.
     34'''TODO:''' Decide whether we adopt the above tentative proposal.
     36=== Reinitialisation after `hs_exit()` ===
     38The FFI addendum currently requires that `hs_exit()` can be followed by another `hs_init()`.  GHC doesn't support that and I am not convinced that we should require it.  I propose to remove that requirement.
     40'''TODO:''' Decide whether we remove the requirement for re-initialisation.
    2245== Integration into the report ==
     47The [ FFI addendum] is already written and formatted in the style of the report — it should be straight forward to integrate.  In addition the following changes relative to the original addendum will be applied.
     49=== Hierarchical names for the libraries ===
     51Changes to the library portion as discussed above under "Open Questions".
     53=== Transparent marshalling of newtypes ===
     55The FFI addendum defines in Section 3.2 that ''The argument types `ati` produced by `fatype` must be marshallable foreign types; that is, each `ati` is either (1) a basic foreign type or (2) a type synonym or renamed datatype of a marshallable foreign type.''  We will improve on the second part of this statement as follows:
     57 * As the transparent marshalling of newtypes (aka renamed datatypes) is a fairly significant features, we will dedicate a separate (sub)subsection to it.
     58 * In contrast to the FFI addendum (and it's implementation in GHC), we require that a newtype in a foreign signature is '''not''' abstract.  Only if its constructor is visible, can the newtype be transparently marshalled.  (After all, marshalling makes only sense if we know the type of the value in foreign land.)  This implies that we will export the newtypes in the modules `Foreign.C.Types` and
     59 * Clarify the connection between marshallable foreign types and the various flavours of foreign signatures discussed in Section 4.1.3.  (E.g., in case of a `foreign import "dynamic"` the whole signature —grammar nonterminal `ftype`— doesn't need to be marshallable, only portions of it.)
     60 * We allow GHC's [ newtype wrapping of the IO monad.]
     61 * We add one or two examples.
    2665== Topics that need discussion for the integration into Haskell' ==
    28 === Transparent marshalling of newtypes ===
    30  1. The *only* reference is in the sentence in 3.2: ''The argument types ati produced by fatype must be marshallable foreign types; that is, each ati is either (1) a basic foreign type or (2) a type synonym or renamed datatype of a marshallable foreign type.''  This is very quiet!  The "renamed datatype" nomenclature is never used in practice (only in the Haskell report), and in any case the sentence is hard to unpick without an example or two.
    31  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".
    32  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.
    33  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.
    35  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.
    37  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).
    39  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.
    4168=== `unsafePerformIO` ===