Changes between Version 5 and Version 6 of ForeignFunctionInterface


Ignore:
Timestamp:
Apr 15, 2006 7:52:52 PM (8 years ago)
Author:
chak@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ForeignFunctionInterface

    v5 v6  
    2121 * Inaccurate `foreign import`s can invalidate all guarantees given by Haskell. 
    2222 
    23 == Issues == 
    24  * Some feel that the inclusion of `unsafePerformIO` sends the wrong signal. 
    25     * It is true that by giving inaccurate `foreign import`s one can define `unsafePerformIO`, but that doesn't mean it should be standard. 
    26     * The stated purpose of `unsafePerformIO` in the FFI (hiding marshalling and unmarshalling for otherwise pure functions) can be achieved with a `runST`-like device if the language has [wiki:Rank2Types] or [wiki:RankNTypes]. 
    27  * Foreign imports may specify a single include file. This is sufficient in theory, but most GHC users prefer to use `-#include` options instead, and the standard form is poorly supported by GHC. The hierarchical libraries use an `INCLUDE` pragma as a portable replacement for `OPTIONS_GHC -#include`. jhc lazily collects the imports needed and only includes the ones needed by the FFI functions used after optimizations. this means you can have FFI calls refering to libraries and includes that are not on a system and still compile the program if none of the routines are used.  
    28  * Cross-platform libraries (e.g. HOpenGL) often want to import the same foreign functions using the `ccall` convention on Unix and the `stdcall` convention on Windows. The usual method is to use CPP hackery. 
    29  * The specified CString conversions are not yet supported in the hierarchical libraries. 
    30  * jhc allows libraries to be specified as well as include files. this is handy for its lazy linking, the syntax is "-lfoo include.h foo_func" 
     23== Topics that need discussion for the integration into Haskell' == 
     24 
     25=== `unsafePerformIO` === 
     26 
     27Some have expressed the opinion that the inclusion of `unsafePerformIO` sends the wrong signal.  They aregue that although it is true that by giving inaccurate `foreign import`s one can define `unsafePerformIO`, but that doesn't mean it should be standard.  Moreover, as the stated purpose of `unsafePerformIO` in the FFI (hiding marshalling and unmarshalling for otherwise pure functions) can be achieved with a `runST`-like device if the language has [wiki:Rank2Types] or [wiki:RankNTypes]. 
     28 
     29 Personally, I don't see the issue.  We are including arbitrary C code.  For this to be safe, there are additional proof obligations.  The function `unsafePerformIO` is the same - for it to be safe, additional proof obligations have to be met.  Concerning a `runST`-like device, if the idea is to limit the scope of effects that are permitted by putting it into another monad and using a different interface, then this will at least complicate the API quite considerably.  Currently, marshalling is performed by functions that read and write arbitrary memory locations.  The FFI needs these functions anyway; hence, any other marshalling would need to add functions in addition to the existing ones.  Secondly, marshalling is somewhat unpredictable in that different C libraries require different marshalling.  Providing an interface with limited effects that captures all possible situations seems tricky, but if anybody has a concrete proposal, let's see it. 
     30 
     31  -- ManuelChakravarty 
     32 
     33=== Include files === 
     34 
     35Foreign imports may specify a single include file. This is sufficient in theory, but most GHC users prefer to use `-#include` options instead, and the standard form is poorly supported by GHC. The hierarchical libraries use an `INCLUDE` pragma as a portable replacement for `OPTIONS_GHC -#include`. jhc lazily collects the imports needed and only includes the ones needed by the FFI functions used after optimizations. this means you can have FFI calls refering to libraries and includes that are not on a system and still compile the program if none of the routines are used.  
     36 
     37 The rationale behind the design in the addendum is that for cases where a single include files does not suffice, you can always write your own include file that does something more clever (and include that from Haskell).  Include files can be used in so many different ways that any other solution, while covering some more complex uses, will never cover them all, which will force people into the fallback of providing extra include files anyway. 
     38 
     39  -- ManuelChakravarty 
     40 
     41=== `ccall` vs. `stdcall` === 
     42 
     43Cross-platform libraries (e.g. HOpenGL) often want to import the same foreign functions using the `ccall` convention on Unix and the `stdcall` convention on Windows. The usual method is to use CPP hackery. 
     44 
     45 Earlier versions of the FFI addendum had another conventions that would automatically adapt.  IIRC we remove this eventually, because it wasn't always sufficient.  Before considering this again, we should consult the mailing list archives for the exact reason of the earlier removal. 
     46 
     47  -- ManuelChakravarty 
     48 
     49=== `CString` === 
     50 
     51The specified CString conversions are not yet supported in the hierarchical libraries. 
     52 
     53 Is this a Haskell' issue? 
     54 
     55  -- ManuelChakravarty  
     56 
     57=== Specifying libraries === 
     58 
     59jhc allows libraries to be specified as well as include files. this is handy for its lazy linking, the syntax is "-lfoo include.h foo_func" 
     60 
     61 This is another feature that we had for a while and then removed as it didn't always work.  I think this is something the package manager should handle. 
     62 
     63  -- ManuelChakravarty