Mon Feb 21 07:28:50 EST 2005
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
* 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).
* 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.
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
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
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
(-) 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"
(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).
More information about the FFI