FFI typing issues [was: Typing f.e.d.]
Sven Panne
Sven.Panne at informatik.uni-muenchen.de
Mon Apr 30 10:42:02 EDT 2001
Some time ago it was agreed that the typing of `foreign export dynamic'
should be changed from
prim_type -> IO Addr
to
prim_type1 -> IO (FunPtr prim_type2) -- where prim_type1 == prim_type2
and deprecating (but keeping) the old typing. While hacking around in GHC's
sources to implement this, I came across a few other typing issues.
The first one is the typing of `foreign import dynamic', which is
documented as
Addr -> (prim_args -> IO prim_result)
GHC currently implements more or less `Addr -> prim_type', but that's not
the point here. I propose changing this to
FunPtr prim_type1 -> prim_type2 -- where prim_type1 == prim_type2
again deprecating and keeping the old typing. Apart from the purely
technical `IO' (hmmmm, is this *really* necessary?), it makes things
almost symmetrical to f.e.d.
Another point is the typing of `foreign label', which is currently simply
Addr
I propose to change this to *two* possible typings:
Ptr a
FunPtr a
because it's not clear if we refer to a data pointer or to a function
pointer. This doesn't look particularly nice, or am I missing something
here?
A last point is the relationship between data type renamings and the FFI:
Although we often say that `the FFI looks through newtype' (and `type',
of course), it currently only does at certain points, e.g.
newtype Foo = Foo Int32
type Bar = Foo -> Word32
foreign import baz :: Bar
is allowed, but
newtype Blah = Blah (Int32 -> Word32)
foreign import booh :: Blah
is not. Should we make newtype completely transparent? I'm not sure what
this really buys us, but at least it would make the description of the FFI
somewhat simpler. I don't have a very strong opinion about this, so I'd
like to hear what other people think.
Cheers,
Sven
More information about the FFI
mailing list