|Version 22 (modified by 7 years ago) (diff),|
Foreign Function Interface
The Foreign Function Interface (FFI) adds support for invoking code and accessing data structures implemented in other programming languages and vice versa. The current proposal encompasses a general mechanism for inter-language operations as well as specific support for interoperating with the C programming language.
- Widely accepted and used addendum.
- Provides an essential facility.
- Inappropriate use can subvert all semantic guarantees provided by Haskell and can cause memory corruption and program crashes.
The following topics still require a bit of discussion or a decision between multiple alternatives.
The 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.
TODO Decide whether we remove the requirement for re-initialisation.
allocaBytes, the original FFI addendum does not specify any constraints on alignment for allocated memory (by
mallocForeignPtrBytes and others). This is clearly an oversight. The questions is how we want to express the fact that all routines that allocate memory specified in bytes must conform to a set of alignment constraints (this was proposed by Thomas DuBuisson and John Meacham) We may add the following statement concerning alignment at the beginning of Section 5 (which describes the library modules):
All storage allocated by functions that allocate based on a size in bytes must be sufficiently aligned for any of the basic foreign types (see Section 3.2) that fits into the newly allocated storage. All storage allocated by functions that allocated based on a specific type must be sufficiently aligned for that type. Array allocation routines need to obey the same alignment constraints for each array element.
TODO Decide whether we want to add this text. If not, we need to find an alternative way of expressing the required alignment constraints.
Integration into the report
The 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.
We use the hierarchical names from the standard library, instead of the names in the FFI addendum.
Moreover, the current libraries have grown somewhat since the original FFI Addendum. We include the additions listed in the following:
Foreign.Marshal.Errordoes actually omit some routines of the FFI Addendum . I think we need to keep them in the FFI specification.
Furthermore we add:
castCSCharToChar(i.e., not only for CChar of which it is platform-dependent whether it is signed or not).
- Add types from ISO C99 (with conversion routines):
WordPtr uintptr_t WordMax uintmax_t IntPtr intptr_t IntMax intmax_t ptrToWordPtr :: Ptr a -> WordPtr wordPtrToPtr :: WordPtr -> Ptr a ptrToIntPtr :: Ptr a -> IntPtr intPtrToPtr :: IntPtr -> Ptr a
- We do not include
Foreign.Marshal.Poolin the standard as it doesn't appear to be widely used and doesn't have an efficient implementation at the moment.
- We omit the functions that, in the standard libraries, have been moved from
System.IO.Error(namely those to construct I/O errors).
Transparent marshalling of newtypes
The 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:
- As the transparent marshalling of newtypes (aka renamed datatypes) is a fairly significant features, we will dedicate a separate (sub)subsection to it.
- 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
- 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.)
- We allow GHC's newtype wrapping of the IO monad.
- We add one or two examples.
Multi-threading support is implementation-specific.