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