Folks, After another teaching-enforced pause, I have continued working at the FFI Report: http://www.cse.unsw.edu.au/~chak/haskell/ffi.ps.gz For C, the report should now be essentially complete (I have included all the libraries). There are, however, still some outstanding issues (see the report and below for the gory details). For all calling conventions other than ccall and stdcall, most is still missing. My plan for driving this further is as follows: * Get all but the most controversial outstanding issues for the language-independent and the C binding fixed until ICFP. * Have a meeting at ICFP to nail any remaining issues in the language-independent and C binding as well as discuss how much we exactly want to do for other calling conventions and how we go about doing it. Could everybody who is coming to ICFP and would like to attend the meeting drop me a note please? Just so that we can fix when to meet. I will be in Florence from Saturday around noon until the following Friday (maybe even Saturday) noon. Cheers, Manuel PS: The source of the document is in cvs.haskell.org and at <http://www.cse.unsw.edu.au/~chak/haskell/ffi.tex>. -=- The Gory Details(TM) -=- I went through all messages on this list that I hadn't responded to yet and either included the suggestions or they are discussed below. "static" keyword ~~~~~~~~~~~~~~~~ Marcin wrote re removing the "static" keyword in C extents,
What the lack of static takes away is the ability to import a function called "dynamic" or "wrapper". I don't think that it's a big limitation considering hundreds of names which are taken away by a Haskell's runtime system.
IHMO, it is one thing for an implementation to do that and another for a language definition.
Anyway, we could call them "_dynamic" and "_wrapper" to indicate that they are magical in some sense - using such names for external function names would be a violation of ISO/ANSI C rules (they are reserved for the C implementation).
*urgh* I think, that's uglier than having "static". So, I'll stick with static unless there are serious counter arguments. Backward compatibility ~~~~~~~~~~~~~~~~~~~~~~ Malcolm raised the issue of backward compatibility. As I understand it we aren't concerned about the definition actually encompassing the syntax and semantics currently implemented in GHC and NHC, but there is an understanding that those system will allow the "old" syntax for a while after they adopt the standard. NHC's current implementation of "foreign export" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From the discussion, it seems that NHC simply allows the phrase "foreign export" in front of the normal type signature of a function (as opposed to in addition to that type signature). I never had this in mind and it has always been different in GHC and in Sigbjorn's FFI spec. In fact, being able to have
foo :: Num a => a -> a foo = ... foreign export foo :: Int -> Int was always sold as a feature of the system. Further additions to the FFI ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ IMHO, the FFI should really be self-contained and not rely on other non-standardised extensions/libraries. Therefore, I propose some additions. * I think, we should include the `Bits' module (or something similar). It is needed, eg, to handle bindings to C functions that expect bit vectors as arguments. * To implement marshalling for foreign imported pure functions, `unsafePerformIO' is essential. We could add it to the module `Foreign' or `MarshalUtils'. This raises the question of whether `unsafeInterleaveIO' falls in the same category. I think, we should add `unsafePerformIO' and leave `unsafeInterleaveIO' our as it is less important for the FFI. * Why do we only have `Eq' on ForeignPtr, but also `Ord' and `Show' on Ptr? I'll add `Ord' and `Show' to `ForeignPtr' unless their are objections. * Should HsFFI.h include a function like GHC's startupHaskell()? For linking Haskell libraries into foreign code that seems to be necessary. So, I vote for inclusion. Superflous stuff ~~~~~~~~~~~~~~~~ * I am still not convinced that we need `Storable.destruct'. For deallocating special purpose structures that need a deep traversal, shouldn't we just use a custom function? * I am also not really convinced about `MarshalUtils.withMany'. There may be situations, where such a function is handy, but should it really be in the standard libraries? Moreover, it isn't really marshalling specific - it is JAFL (Just Another Function on Lists). Names ~~~~~ * I don't think `CTypesISO' is a good name. Maybe `CTypesLib' as it contains the types from the C library (as opposed to the normal builtin types)? Or put it all into `CTypes' after all - that doesn't mean GHC (or any other compiler) has to put it into a single module, just for the definition. I tend to having one module only. PtrDiff ~~~~~~~ Maybe after all, `PtrDiff' wasn't that bad an idea. To assume that a pointer difference fits into an `Int' (what we do at the moment) is pretty dodgy. Remember that all that H98 requires of an `Int' is that it has >=30 bits. IMHO, this is pretty weak for a general representation of a pointer difference. The annoying thing about our old use of `PtrDiff' was that it made `plusPtr' a pain to use (as we had to cast the offset to a `PtrDiff' first). A simple solution would be plusPtr :: Integral i => Ptr a -> i -> Ptr b I am actually pretty convinced that this is the right way to go. Argument types for foreign functions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As you can see, I have removed my construction for using `Storable' to specify the types that can be used as arguments to foreign functions. However, I don't agree with the posts claiming that this route would be unworkable. Whenever a type `T' is `Storable', it can be passed to a foreign function in one of two ways: (1) The compiler has special knowledge about the type and just generates the normal (possibly type-dependent) argument passing code. (2) If the compiler has no special knowledge about the type, it `alloca's temporary storage for the type and `poke's the argument into that location. Then, it generates a stub routine in the foreign language that gets a pointer to the temorary storage instead of the actual argument. The stub routine extracts the argument and calls the actual foreign routine. The idea is of course that the compiler (at least if it aspires to generate decent code) has special knowlegde about all the standard types. So, (2) is only the fallback for weird user-defined instances of `Storable'. (+) I like this approach, because it makes the FFI definition nicer. (-) Unfortunately, it is more fuss for the implementation and probably doesn't make a big difference in practice. I have removed it from the report, because "worse is better"[1] (at least that's what some people claim; although it is somewhat against the spirit of Haskell, which tends to put elegance over simplicity of implementation). [1] http://www.jwz.org/doc/worse-is-better.html