FFI Report, CVS Id 1.5

[Marcin 'Qrczak' Kowalczyk]

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
classes:-(

>     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
QRCZAK