FFI Report, CVS Id 1.11
Malcolm.Wallace at cs.york.ac.uk
Tue Aug 21 06:06:10 EDT 2001
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
> Superfluous stuff
> * I am still not convinced that we need `Storable.destruct'.
> * I am also not really convinced about `MarshalUtils.withMany'.
> * I don't think `CTypesISO' is a good name. Maybe `CTypesLib'.
No strong opinion, but if the ISO suffix is inaccurate, Lib would be
> 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.
More information about the FFI