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
foreign import "static foo" foo :: t foreign import "static" foo :: t foreign import "" foo :: t
Is the last one nice?
(I still think that the "static" keyword is not necessary.)
How would you import a function named "static" then?
I don't know whether we are still worrying about backwards compatibility, but foreign import "static" foo :: t at the moment declares a function called "static" in the foreign language and "foo" in Haskell. Is the idea that, in the new scheme, this declares a function called "foo" in both Haskell and the foreign language, but with an attribute "static" in the foreign domain? And so to declare the former kind of thing, we'd need foreign import "static static" foo :: t ? I don't much mind either way, since it is a trivial and unlikely situation, but could someone clarify please?
I have added a restriction: exported variables must be defined by a function or pattern binding in the *same* module.
I had understood that this was always the case anyway. foreign export f :: t is the sole type declaration for f. Just as it is an error to have more than one type decl for f, so you can't write an additional f :: t in the same file. And just as you cannot write a type decl for an entity imported from a different module, you can't write a foreign export for an imported entity either.
Again, I'm with Marcin. This restriction looks very artificial and ugly.
On the contrary, I think it is a very natural interpretation. That is also how it is implemented in nhc98, which is something I need to keep my eye on of course - I am not a type system hacker, and I'm afraid I wouldn't know how to implement it any other way currently. Regards, Malcolm
Sven Panne <Sven_Panne@BetaResearch.de> writes:
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.
I haven't been following the Storable stuff very closely but this mail made me think about the CCallable/CReturnable stuff currently in GHC (for which SimonPJ and I share the blame). Is CCallable/CReturnable a useful part of the new multi-lingual ffi story (either in the ffi spec or in GHC's implementation of the ffi spec)? I think the answer is no: being able to pass a given type to C doesn't necessarily the same as being able to pass that same type to Java or C#. They could be supplemented by new classes with names like {Java,C_Sharp,Python,...}{Callable,Returnable} but that would be ugly. -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
On Tue, Jun 12, 2001 at 11:00:09AM +0200, Sven Panne wrote:
(I still think that the "static" keyword is not necessary.)
How would you import a function named "static" then?
There can't be such a function: it's a keyword in C :-P And even if it was allowed in C, without any special meaning of "static" inside the external entity specification there would be no problem with importing it - just write "static". What the lack of static takes away is the ability to import a function called "dynamic" or "wrapper". I don't think that it's a big limitation considering hundreds of names which are taken away by a Haskell's runtime system. Anyway, we could call them "_dynamic" and "_wrapper" to indicate that they are magical in some sense - using such names for external function names would be a violation of ISO/ANSI C rules (they are reserved for the C implementation). -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTĘPCZA QRCZAK
participants (4)
-
Alastair David Reid -
malcolm-ffi＠cs.york.ac.uk -
Marcin 'Qrczak' Kowalczyk -
Sven Panne