Thanks Manuel for all your work on this document. It looks in pretty good shape to me. This message contains my reactions to the "gory details" from your summary. In another message I'll post some comments on the document itself.
"static" keyword ~~~~~~~~~~~~~~~~ So, I'll stick with static unless there are serious counter arguments.
Fine by me.
Backward compatibility ~~~~~~~~~~~~~~~~~~~~~~ As I understand it we aren't concerned about the definition actually encompassing the syntax and semantics currently implemented.
The actual surface syntax changes are fairly small anyway, so I have no problem with that, and the whole point is to firm up the semantics.
NHC's current implementation of "foreign export" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ being able to have foo :: Num a => a -> a foreign export foo :: Int -> Int was always sold as a feature of the system.
Ok. It wasn't how I read Sigbjorn's original document, but it does seem like a fairly reasonable thing to want to do. Like Alastair says for Hugs though, I'm not entirely sure how to implement it in nhc98, so it may remain as a 'bug' for us too.
Further additions to the FFI ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ IMHO, the FFI should really be self-contained and not rely on other non-standardised extensions/libraries.
Yes, that seems reasonable.
* I think, we should include the `Bits' module. * `unsafePerformIO' is essential. * I'll add `Ord' and `Show' to `ForeignPtr'. * Should HsFFI.h include a function like GHC's startupHaskell()?
Ok to all of these. Nhc98 has haskellInit() rather than startupHaskell(), which just goes to show that if you don't define these things to be standard, implementations will diverge almost immediately.
Superfluous stuff ~~~~~~~~~~~~~~~~ * I am still not convinced that we need `Storable.destruct'.
Agree.
* I am also not really convinced about `MarshalUtils.withMany'.
No opinion.
Names ~~~~~ * I don't think `CTypesISO' is a good name. Maybe `CTypesLib'.
No strong opinion, but if the ISO suffix is inaccurate, Lib would be better.
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.
I agree. However this brings up a wider issue, because the methods of class Storable and functions like mallocBytes also assume that a 30-bit Int will be big enough. Even today some people have machines with gigabytes of RAM, so I don't want the FFI to become inadequate in only a few more years time when multi-gigabytes become common.
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.
No strong opinion. Regards, Malcolm