FFI Report, CVS Id 1.5

Marcin 'Qrczak' Kowalczyk qrczak at knm.org.pl
Sat Jun 9 10:45:33 EDT 2001

Sat, 09 Jun 2001 23:25:08 +1000, Manuel M. T. Chakravarty <chak at cse.unsw.edu.au> pisze:

> The new definition reduces the problem of defining exactly
> which types can be marshalled to a reference to Storable.

Being just Storable is not enough to generate a foreign call. For
example floating point arguments might be passed in different registers
than integer arguments. So what should happen when the programmer
makes a Storable instance for some weird type?

(Storable.peek would be needed for importing, not exporting, and vice
versa for poke - you wrote it backwards.)

> Consequently, Storable must be derivable.

Ok, but it's not enough.

I hope that generics will subsume some uses of deriving, but for that
they must be fixed (as I told a long time ago). In particular I hope
that generics will cover Storable and Dynamic. It seems that even if
they are fixed, it's not enough to write generic instances of these

>     foreign import "static foo" foo :: t
>     foreign import "static"     foo :: t
>     foreign import ""           foo :: t
>   Is the last one nice?

Not nice and not necessary if the whole "" can be omitted, but it
makes rules more consistent. In particular this should be legal:
    foreign import "&" foo :: Ptr t
so with "static" too...

(I still think that the "static" keyword is not necessary.)

> I have added a restriction: exported variables must be
> defined by a function or pattern binding in the *same*
> module.
> This shouldn't be a serious restriction in practice, but
> may make live easier for some systems.

Why? The implementation could always generate a wrapper.

And it is possible to do a non-FFI export of entities defined in
other modules (even written qualified), so FFI exporting rules could
be consistent with it.

 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
  ^^                      SYGNATURA ZASTÊPCZA

More information about the FFI mailing list