Sat, 09 Jun 2001 23:25:08 +1000, Manuel M. T. Chakravarty <chak@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@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK