Marcin wrote:
Being just Storable is not enough to generate a foreign call.
Exactly.
For example floating point arguments might be passed in different registers than integer arguments. [...]
... or 'long long's being passed in a register pair, starting at an even register number. :-P (happens on PowerPC g++) I think it boils down to the following: For every calling convention there is a fixed set of primitive types which the Haskell system must know about, e.g. CInt, CFloat, Ptr a, ... for ccall/stdcall. The only convenience which can be offered for the programmer are opaque newtypes around these types or automatic flattening of pure product types (like e.g. GreenCard does for tuples IIRC). Marshaling and parameter passing are two different things. In a nutshell: Nice at it seems, the Storable-idea has to be replaced by something else, I fear.
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'm with Marcin here.
(I still think that the "static" keyword is not necessary.)
How would you import a function named "static" then?
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.
Again, I'm with Marcin. This restriction looks very artificial and ugly. Cheers, S. P.S.: Regarding the funny restriction on the type of f.i.d.: This has in effect been removed & fixed in GHC's implementation. -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de