Sat, 09 Jun 2001 23:25:08 +1000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> 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 * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
